Note |
---|
Before using this information and the product it supports, be sure to read the general information under Appendix A, Notices. |
Sixth Edition (Sept 2000)
This edition applies to the IBM token-ring adapters.
You can submit comments online to http://www.networking.ibm.com/support/feedback.nsf/docsoverall.
© Copyright International Business Machines Corporation 1998, 1999, 2000. All rights reserved.
Note to U.S. Government Users -- Documentation related to restricted rights -- Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule contract with IBM Corp.
Network adapter performance tuning
This manual contains information about installing and configuring the features of IBM token-ring adapters.
This manual is intended for use by network administrators and other end users who install and configure the features of IBM token-ring adapters.
Introduction describes where to download the software for your adapter.
RPL/PXE describes the Remote Program Load (RPL) function for your adapter.
IBM LAN Client describes how to install and configure the IBM LAN Client.
LAN Adapter Management Agent describes how to install and configure the IBM LAN Adapter Management Agent.
Route Switching describes how to install and configure Route Switching.
Class of Service describes how to install and configure the Class of Service (CoS) for IP function.
Redundant NIC describes how to install and configure the Redundant NIC function.
Load Balancing and Failover describes how to install and configure the Line Balancing and Failover function.
Tivoli Management Agent describes how to install and configure the Tivoli Management Agent.
Network adapter performance tuning describes how to get the best performance from your adapter.
Refer to these publications for additional information:
Novell documentation can be obtained by contacting Novell on the Web or by calling their toll-free number:
http://www.novell.com 1-800-NETWARE (1-800-638-9273)
IBM adapter books and other documentation are available on the IBM Networking Web site:
http://www.ibm.com/networking
A local area network (LAN) adapter exists at the intersection of two complex environments--the computer and the network. The purpose of this manual is to provide the additional information necessary to extend the function of your token-ring adapter in the dimensions of the computer and the network.
This manual complements the installation and testing instructions manual or the user's guide for your adapter.
Operating efficiently in complicated multi-vendor environments requires a standards-based solution. The features in this manual are based on industry-wide standards such as the Intel(R) Wired for Management Baseline, the DMTF Desktop Management Interface, and the IETF Next Hop Routing Protocol. These standards-based solutions create a solid foundation for future enhancements necessary to keep pace in an ever-changing networked world.
These features take advantage of the increasing processing power in computers and provide adapter-based solutions in the areas of remote system setup, manageability, IP switching, class of service, and high availability. These solutions help your computer and network operate at a higher level of efficiency.
You should be familiar with the computer in which the features will be installed and the computer's operating system and network software.
You can download the software implementing these features from the adapter CD-ROM or from the Web.
This procedure applies to the following adapters:
To download software from the CD-ROM, perform the following steps:
This procedure applies to the following adapters:
To download software from the CD-ROM, perform the following steps:
To download software from the Web, perform the following steps:
Select the appropriate adapter from the list of IBM Networking Hardware products and then select Downloads. Select an operating system to expand its section, and then select a download package.
This chapter describes the Remote Program Load (RPL) feature and the Preboot Execution Environment (PXE) feature.
If you are using the IBM Turbo 16/4 Token-Ring PC Card 2, see IBM Turbo 16/4 Token-Ring PC Card 2 RPL feature. Otherwise, see the following information.
RPL is supported on the following PCI adapters:
The adapter supports RPL from the following servers:
PXE is supported by several IBM token-ring PCI adapters.
Note: | Consult your system administrator for information about whether your server supports PXE. |
PXE is supported on the following adapters:
The RPL feature enables an adapter to boot a computer using files that the computer receives from a LAN server. The computer that requests these files is referred to as the client computer, and the computer that responds with these files is referred to as the LAN server. In order for RPL to take place, two things must occur. First, the RPL feature of the adapter in the client machine initiates the RPL request. Second, a LAN server responds to the RPL request with the files to bring up, or boot, the client computer.
The PCI token-ring adapters support PXE from any server that supports PXE 2.x. You can download the PXE specification from http://developer.intel.com/ial/wfm/wfmspecs.htm.
The following topics are addressed in this section:
For the RPL/PXE process to begin, the feature must be enabled on the adapter installed in the client computer, and the client computer must recognize the RPL/PXE feature of the adapter as the first or only bootable device present.
The adapter is shipped with the RPL/PXE feature enabled. You can ensure that it is enabled by running the diagnostics and, at the diagnostics test panel, pressing F5 to view or change the RPL setting.
All IBM PCs support RPL, and many IBM-compatible PCs also do. If your computer is not an IBM PC, refer to your computer's user's manual or contact the manufacturer if you are not sure whether it supports RPL.
On most IBM PCs you can make this adapter the first bootable, or startup, device by choosing Network as the first startup device in the startup sequence in the configuration utility (usually you enter the configuration utility by pressing F1 when the IBM logo and Configuration Utility program symbol appear during the power-on process). If drive A is the first bootable device, consider making the adapter the second bootable device. Refer to the user's manual for your IBM PC if you need further instructions for altering the startup sequence or entering the configuration utility.
Many non-IBM machines and some older IBM machines do not have a configuration utility, or do not allow a choice of a network-bootable device in the configuration utility. On these machines you can either remove the hard disk or use the RPLENABL.EXE utility program provided with this adapter in the RPLPKG.EXE package on the CD-ROM to disable the hard disk as a bootable device. After the hard disk is disabled as a bootable device, computers that support RPL adapters will attempt to boot from the network as long as no diskette is in the diskette drive.
The procedure for changing the boot protocol depends on your adapter's microcode level. To determine your adapter's microcode level, look at the AL- field displayed on the DHCP/PXE or RPL screen. There are two fields displayed, such as AL-00001 ALB1BG2.
If the second field has only six digits, or if the seventh digit is "1", as shown in the following examples, the microcode supports PXE 1.
AL-00001 PX10AH AL-00001 ALB1BG1
If the seventh digit is "2", as shown in the following example, the microcode supports PXE 2.
AL-00001 ALB1BG2
The following adapters ship with PXE 1:
A PXE 2 flash update is available for these adapters at http://www.ibm.com/networking/support.
For the procedure to change the boot protocol, see Changing the boot protocol (PXE 1.x).
The following adapters ship with PXE 2:
A PXE 1 flash update is available at http://www.ibm.com/networking/support.
For the procedure to change the boot protocol, see Changing the boot protocol (PXE 2.x).
If the microcode on your adapter is flashed to support PXE 1.x, use the following procedure to change the boot protocol. If the microcode on your adapter is flashed to support PXE 2.x, see Changing the boot protocol (PXE 2.x).
After you select RPL as the first startup, or boot, device you will see a DHCP panel when your client machine is booting. By default, the adapter will first try Dynamic Host Configuration Protocol (DHCP) as the first protocol. Any time before the client has connected to the DHCP server, you can press Alt+S to switch to RPL. The following figure is an example of the DHCP panel:
+--------------------------------------------------------------------------------+ | IBM PCI Token-Ring DHCP | | ET-02:15:36 | | ID-268 0030 | | BU-0000 | | AA-0004AC570001 | | AL-000001 PX10AH | | BL-CD0110 | | RM-C800 | | OP-0000 16 | | | | DD-0002 | | AR- | | DR- | | XR- | | TR- | | AC-8C00 00002000 8820 | | AE-000 OP-0011 | | Press ALT-S to switch to RPL | | Press ESC to return to BIOS | | Ending DHCP | +--------------------------------------------------------------------------------+
+--------------------------------------------------------------------------------+ | IBM PCI Token-Ring RPL | | ET-02:15:36 | | ID-268 0030 | | BU-0000 | | AA-0004AC570001 | | AL-000001 PX10AH | | BL-CR1.0243 | | RM-C800 | | OP-0000 16 | | | | RQ-000F | | SF- | | SN- | | RS-2010 | | PC-0606 | | AC-8C00 00002000 8820 | | AE-000 OP-0011 | | Press ALT-S to switch to DHCP | | Press ESC to return to BIOS | | Ending RPL | +--------------------------------------------------------------------------------+
This example shows all of the possible error and status message prefixes. You will normally not see the error status condition prefixes, such as PC-, unless an error condition occurs. These error and status messages are described in RPL messages.
If the microcode on your adapter is flashed to support PXE 2.x, use the following procedure to change the boot protocol. If the microcode on your adapter is flashed to support PXE 1.x, see Changing the boot protocol (PXE 1.x).
Current operating system software installation programs either require your attendance in order to enter information in response to system prompts (attended installation) or do not require your attendance (unattended installation). To accommodate this mix of attended versus unattended, a menu in the Token Ring Option ROM is provided to guide you in setting up your Token Ring Option ROM.
You can access the menu at Option ROM initialization time. Use this menu to change the protocol (RPL or PXE) and the protocol's behavior if the protocol fails to reach a boot server of the selected protocol or if the initial bootstrap returns control to the boot ROM code.
At option ROM initialization time, the following line is displayed:
+--------------------------------------------------------------------------------+ |Token-Ring ROM Initializing...... | +--------------------------------------------------------------------------------+
After the line appears, you have 5 seconds to press Ctrl+S to access the PCI Token Ring's boot protocol/protocol failure menu, as shown in the following example. If you do not press Ctrl+S within five seconds, the PCI token-ring's option ROM settings remain unchanged and the system boot continues.
If you press Ctrl+S within five seconds, the following options are displayed:
+--------------------------------------------------------------------------------+ |Token-Ring ROM Initializing...... | |1 PXE/Local Boot <<<< Current Mode | |2 PXE only | |3 RPL/Local Boot | |4 RPL only | |5 Local Boot | |ESC-No Change | +--------------------------------------------------------------------------------+
Note: | <<<< Current Mode displayed beside an option indicates the current adapter setting. If you change the setting, <<<< Current Mode will display next to the new option the next time you reboot your system. |
The options are described in the following table:
Option | Description |
---|---|
1 PXE/Local Boot | Use the PXE protocol. If the PXE protocol fails, or the initial downloaded bootstrap returns control to the token-ring adapter's boot ROM code, the boot ROM code will return control back to BIOS, and onto the next boot device. |
2 PXE only | Use the PXE protocol. If the PXE protocol fails, or the initial downloaded bootstrap returns control to the token-ring adapter's boot ROM code, the boot ROM code will retry the PXE protocol. This will continue indefinitely. |
3 RPL/Local Boot | Use the RPL protocol. If the RPL protocol fails, or the initial downloaded bootstrap returns control to the token-ring adapter's boot ROM code, the boot ROM code will return control back to BIOS, and onto the next boot device. |
4 RPL only | Use the RPL protocol. If the RPL protocol fails, or the initial downloaded bootstrap returns control to the token-ring adapter's boot ROM code, the boot ROM code will retry the RPL protocol. This will continue indefinitely. |
5 Local Boot | This option informs BIOS that this option ROM is not an IPL device, and therefore the option ROM will not be called to execute its boot protocol. |
ESC | The current boot protocol or protocol failure is unchanged. |
Select an option by pressing the option's number on the number row on your keyboard or on the numeric keypad (with the NumLock function enabled). The display confirms your selection.
Remember the following key points:
If you select 1 PXE/Local Boot or 2 PXE only, a series of panels appear. The first panel appears during the initialization and opening of the adapter onto the ring.
+--------------------------------------------------------------------------------+ | PCI Token-Ring PXE CS2| |ET-00:00:00 016| |ID-2460 068 | |BU-0000 | |AA-00112233445566 | |AL-000001 PX14CN2 | |BL-CS200 | |RM-C800 | |OP-0000 0016 | | | | | | | | | | | | | | | | | | | |RS-2010 | |AC/PC-0606 | |AE-000 OP-0011 | | | +--------------------------------------------------------------------------------+
The second panel appears after the adapter successfully opens onto the ring and starts the PXE/DHCP protocol.
+--------------------------------------------------------------------------------+ | PCI Token-Ring PXE CS20| |ET-00:00:00 016M| |UU-11223344556677889900112233445566 IP-17.17.17.2 | |DD-0001 SM-255.255.255.0 | |AR-0002 DHCPSvr-10.10.10.3 | |DR-0001 Router-17.17.17.8 | |XR-0001 SR1-0.0.0.0 | | SR2-0.0.0.0 | | BINL-10.10.10.5 | | | | | | | |TF- TFTP IP-10.10.10.5 TFTPGW-17.17.17.8 | |c:\path\filename.ext | |Press space bar to suspend NBP download | | | | | | | | | |RS-2010 | |AC/PC-0606 | |AE-000 OP-0011 | +--------------------------------------------------------------------------------+
The third panel appears if the boot server has provided a PXE Boot menu giving you the option of which boot server to use.
+--------------------------------------------------------------------------------+ | PCI Token-Ring PXE CS20| |ET-00:04:10 016M| |Select Boot Server 10 IP-17.17.17.2 | |Local Boot SM-255.255.255.0 | |Bootserver 1 DHCPSvr-10.10.10.3 | |Bootserver 2 Router-17.17.17.8 | | SR1-0.0.0.0 | | SR2-0.0.0.0 | | BINL-10.10.10.5 | | | | | |BD-0001 BootSrv-10.10.10.4 | |TF-0001 TFTP IP-10.10.10.5 TFTPGW-17.17.17.8 | |c:\path\filename.ext | |Press space bar to suspend NBP download 3 | |BIS-21 | | | | | | | |RS-2010 | |AC/PC-0606 | |AE-000 OP-0011 | +--------------------------------------------------------------------------------+
If you select 3 RPL/Local Boot or 4 RPL only, the following panel appears.
+--------------------------------------------------------------------------------+ | PCI Token-Ring RPL | | ET-00:15:36 | | ID-268 0030 | | BU-0000 | | AA-0004AC570001 | | AL-000001 PX14CN2 | | BL-CS200 | | RM-C800 | | OP-0000 0016 | | RQ-000F | | SF- | | SN- | | RS-2010 | | PC-0606 | | AC-8C00 00002000 8820 | | AE-000 OP-0011 | | | +--------------------------------------------------------------------------------+
The example panels show all of the possible error and status message prefixes. You will normally not see the error status condition prefixes, such as PC-, unless an error condition occurs. These error and status messages are described in RPL messages.
This manual assumes that you have already set up your OS/2 LAN Server for RPL and installed the DOS or OS/2 RPL image. If you have not, refer to the OS/2 LAN Server documentation and install RPL support before installing RPL support for the adapter on the OS/2 LAN Server. In summary, at this point you should have already performed the following steps:
Use the OS/2 syslevel command on your OS/2 LAN Server to check the CSD level.
After these steps are complete, run the following steps on the OS/2 LAN Server to add RPL support for the adapter:
Client Operating Environment | Record Identifier |
---|---|
OS/2 3.0 | R_230_DTKTRP |
DOS | R_DTKTRP_NDIS |
The following steps are a sample procedure for creating a NetWare Client boot image:
Place the following files on the bootable DOS diskette:
LSL.COM AUTOEXEC.BAT CONFIG.SYS NET.CFG VLM.EXE IBMTRPO.EXE ROUTE.COM IPXODI.COM REDIR.VLM CONN.VLM SECURITY.VLM NWP.VLM PRINT.VLM IPXNCP.VLM NDS.VLM FIO.VLM NETX.VLM TRAN.VLM BIND.VLM GENERAL.VLM
Your CONFIG.SYS file should have the following statements:
REM Use the DOS= and DEVICE= statements if you want to use high memory and XMS memory. REM DOS=HIGH REM DEVICE=A:\HIMEM.SYS REM DEVICE=A:EMM386.EXE NOEMS FILES=40 BUFFERS=20 LASTDRIVE=Z
Your AUTOEXEC.BAT file should have the following statements:
PATH A:\ SET NWLANGUAGE=ENGLISH LSL IBMTRPO ROUTE IPXODI REM If you issue commands that reload COMMAND.COM, REM you must also copy COMMAND.COM REM to the NetWare Server \system directory and REM uncomment the COMSPEC command statement below. REM SET COMSPEC=F:\SYSTEM\COMMAND.COM VLM LOGIN yourID
Place the following files on the bootable DOS diskette:
IBMTRPO.EXE AUTOEXEC.BAT LSL.COM NETX.EXE ROUTE.COM IPXODI.COM NET.CFG
Your AUTOEXEC.BAT should have the following statements:
PATH A:\ LSL IBMTRPO ROUTE IPXODI REM If you issue commands that reload COMMAND.COM, REM you must also copy COMMAND.COM REM to the NetWare Server \system directory and REM uncomment the COMSPEC command statement below. REM SET COMSPEC=F:\SYSTEM\COMMAND.COM NETX F: LOGIN yourID
Following is a sample of the NET.CFG file for VLM or NETX clients:
Link Driver IBMTRPO FRAME TOKEN-RING MSB DATARATE AUTO RXBUFFERS 9 TXBUFFERS 1 NetWare DOS Requester FIRST NETWORK DRIVE = F NETWARE PROTOCOL = NDS BIND
load rpl bind rpl to <driver>where <driver> is the token-ring driver loaded on your NetWare Server.
Refer to the chapter on Remoteboot in the Microsoft Windows NT Networking Guide for the following features:
At a command prompt on the server, change to the c:\winnt\RPL\bblock\netbeui directory and create a directory named ibmtrp. Within the ibmtrp subdirectory create a PROTOCOL.INI file that has the following data in it:
[protman] drivername = protman$ dynamic = yes priority = netbeui [netbeui_xif] drivername = netbeui$ bindings = ibmtrp_nif names = 6 ncbs = 12 packets = 20 pipeline = 10 sessions = 6 stacksize = 512 lanabase = 0 [ibmtrp_nif] drivername = ibmtrp$ MaxTransmits = 2 MaxTxFrameSize = 2048 MinRcvBuffs = 8 RcvBuffSize = 1120
Also, within that same subdirectory ibmtrp create a DOSBB.CNF file that has the following data in it:
;DOS RPL with IBM PCI Token-Ring Adapter BASE CCH RPL BBLOCK\RPLBOOT.SYS LDR BBLOCK\RPLSTART.COM ~ DAT BBLOCK\NETBEUI\IBMTRP\PROTOCOL.INI DRV BBLOCK\RPLDISK.SYS ~ ~ EXE BBLOCK\RPLPRO1.COM ~ 2 ~ EXE BBLOCK\I13.COM ~ ~ ~ EXE BBLOCK\RPLBIND2.EXE ~ ~ EXE BBLOCK\PROTMAN.EXE ~ ~ EXE BBLOCK\RPLBIND1.EXE ~ ~ ;DRV BBLOCK\IPXNDIS.DOS ~ ~ ~ ;DRV BBLOCK\TCPDRV.DOS /LANMAN.DOS ~ ~ EXE BBLOCK\NETBEUI\NETBEUI.EXE ~ 10 ~ DRV BBLOCK\NDIS\IBMTRP.DOS /NOMSG 22 ~ DRV BBLOCK\PROTMAN.DOS /I:C:\LANMAN.DOS ~ M
Go to http://www.ibm.com/networking/support and download the IBM PCI Token-Ring Adapter driver diskette. Copy the file IBMTRP.DOS from the DOS directory (a:\dos) to c:\winnt\rpl\bblock\ndis
The Windows NT 4.0 Server support for RPL does not include the image for IBM PC DOS.
Note: | If the DOS image is already on the server, skip to Creating Remoteboot configurations for the PCI token-ring adapters. |
Copy c:\dos\*.* v:\binfiles\dos700 Copy c:\command.com v:\binfiles\dos700 Attrib -s -h c:\ibmbio.sys Attrib -s -h c:\ibmdos.sys Copy c:\ibmbio.sys v:\binfiles\dos700\io.sys Copy c:\ibmdos.sys v:\binfiles\dos700\msdos.sys Attrib +s +h c:\ibmbio.sys Attrib +s +h c:\ibmdos.sys
Copy c:\dos\*.* v:\binfiles\dos622 Copy c:\command.com v:\binfiles\dos622 Attrib -s -h c:\io.sys Attrib -s -h c:\msdos.sys Copy c:\io.sys v:\binfiles\dos622\ Copy c:\msdos.sys v:\binfiles\dos622\ Attrib +s +h c:\io.sys Attrib +s +h c:\msdos.sys
From a command prompt on the server, run RPLCMD.EXE. This utility allows you to add boot block records for the adapter and vendor ID. Use the following illustration to set up and configure a boot image for your adapter.
Note: | If you are using MS-DOS 6.22, change all the following references from DOS700* to DOS622* |
c:\> rplcmd Adapter Boot Config Profile Service Vendor Wksta [Quit]: b Add Del Enum: a BootName=DOS700 **rpl client environment** VendorName=002035 **the first 6 digits of the adapter's hexadecimal MAC address** BbcFile=bblock\netbeui\ibmtrp\dosbb.cnf All other parameters are optional BootComment=DOS 700 IBM PCI TOKEN RING WindowSize=0 Adapter Boot Config Profile Service Vendor Wksta [Quit]: v Add Del Enum: a VendorName=002035 **the first 6 digits of the adapter's hexadecimal MAC address** VendorComment=DOS 700 IBM PCI TOKEN RING Adapter Boot Config Profile Service Vendor Wksta [Quit]: c Add Del Enum: a ConfigName=DOS700C BootName=DOS700 DirName=DOS DirName2=DOS700 FitShared=fits\dos700.fit FitPersonal=fits\dos700p.fit All other parameters are optional ConfigComment=DOS 700 IBM PCI TOKEN RING ** Shown in step 4 below ** DirName3= DirName4= Adapter Boot Config Profile Service Vendor Wksta [Quit]: q
ET-00:00:45 |
Explanation: Elapsed Time. A continuously updated field indicating the elapsed time since the RPL feature gained control. |
ID-268 BBDF |
Explanation: Identification. An indication of which adapter is using the RPL feature. 268 indicates a PCI token-ring adapter. BBDF indicates the PCI bus, device, and function number for the PCI slot in which the adapter is inserted. |
BU-0000 |
Explanation: Bring-Up. This field is displayed as X'0000' if the adapter has been successfully initialized and opened. If not, a code other than X'0000' is displayed and the field is highlighted. See Troubleshooting RPL problems. |
AA-08005A2B0000 |
Explanation: Adapter address. The permanently encoded address of the token-ring adapter in your computer. This address is always 12 hexadecimal characters (6 bytes) long. |
AL-000001 PX10AH |
Explanation: Adapter Level. The Engineering Change (EC) level of the code on the token-ring adapter. |
BL-CD0106 |
Explanation: BIOS Level (module level). The EC level of the code in the RPL feature. |
RM-CC00 |
Explanation: Memory (read-only memory). Segment address in memory where BIOS has placed the RPL ROM. |
OP-0000 0004 |
Explanation: Open Return Code. The first 4 digits are X'0000' and the last 4 digits identify the adapter data rate, if the adapter has been successfully opened and attached to the network. If not, a code other than X'0000' is displayed and the field is flashing. See Troubleshooting RPL problems. |
RQ-0001 |
Explanation: Request Count (FIND Frame Count). The number in hexadecimal of FIND frames that have been transmitted. An excessive request count indicates that the LAN server is not present, is congested, or is not correctly configured to RPL this adapter. |
SF-0001 |
Explanation: SEND.FILE.REQUEST Frame Count. The number of SEND.FILE.REQUEST frames that have been transmitted. An excessive SEND.FILE.REQUEST frame count indicates that the LAN server is not responding after having been found. |
SN-0023 |
Explanation: File Response Sequence Number. This value is displayed when the LAN server has responded to the SEND.FILE.REQUEST. It indicates how many times valid FILE.DATA.RESPONSE frames have been received. |
RS-0040 |
Explanation: Ring Status. This field displays a code indicating the status of the network. The field will be highlighted if the operation cannot continue; it will not be highlighted if processing can continue. See Troubleshooting RPL problems. |
PC-4020 |
Explanation: Computer error. This field displays an error code indicating that the adapter has difficulty in functioning with the computer. In most cases, the panel will be frozen and this field will be highlighted because the adapter cannot continue. See Troubleshooting RPL problems. |
AC-0040 0000 0000 0000 |
Explanation: Adapter check. The adapter has detected an internal error and cannot continue. Reboot your computer. If this problem persists, record the adapter check code, and contact your network administrator. |
AE-nnn XX-0011 |
Explanation: Adapter error. The adapter in your computer could not establish communication with the LAN server. The nnn indicates the instance number. The reason for this error is indicated by the XX message to the right of AE-nnn. XX can be either BU or OP. The BU and OP messages are described previously in this section. |
ET-00:00:45 |
Explanation: Elapsed Time. A continuously updated field indicating the elapsed time since the RPL feature gained control. |
ID-268 BBDF |
Explanation: Identification. An indication of which adapter is using the RPL feature. 268 indicates a PCI token-ring Adapter. BBDF indicates the PCI bus, device, and function number for the PCI slot in which the adapter is inserted. |
BU-0000 |
Explanation: Bring-Up. This field is displayed as X'0000' if the adapter has been successfully initialized and opened. If not, a code other than X'0000' is displayed and the field is highlighted. See Troubleshooting RPL problems. |
AA-08005A2B0000 |
Explanation: Adapter address. The permanently encoded address of the token-ring adapter in your computer. This address is always 12 hexadecimal characters (6 bytes) long. |
AL-000001 PX10AH |
Explanation: Adapter level. The Engineering Change (EC) level of the code on the token-ring adapter. |
BL-CD0106 |
Explanation: BIOS level (module level). The EC level of the code in the RPL feature. |
RM-CC00 |
Explanation: Memory (read-only memory). Segment address in memory where BIOS has placed the RPL ROM. |
OP-0000 0004 |
Explanation: Open return code. The first 4 digits are X'0000' and the last 4 digits identify the adapter data rate, if the adapter has been successfully opened and attached to the network. If not, a code other than X'0000' is displayed and the field is flashing. See Troubleshooting RPL problems. |
DD-0001 |
Explanation: DHCP discover count. The number in hexadecimal of DHCP Discover frames that have been transmitted. The field will be highlighted with a value of 0004 10 if the server is not present, is congested, or is not currently configured to respond to DHCP messages. |
AR-0001 |
Explanation: ARP request count. The number in hexadecimal of ARP Requests broadcasted onto the network. If the field is highlighted as XXXX 00, the client received a reply to its ARP request. Check to see if any other machine is assigned the client's IP address and check the DHCP server's DHCP scope of addresses. |
DR-0001 |
Explanation: DHCP request count. The number in hexadecimal of DHCP Request packets transmitted to the DHCP server/Proxy DHCP server. The field will be highlighted with a value of XXXX 10 if the server is not present, is congested, or is not correctly configured to respond to DHCP Request messages. |
XR-0001 |
Explanation: Extended DHCP request count. The number in hexadecimal of Extended (PXE) DHCP Request packets transmitted to the Boot Image Negotiation Layer (BINL) server. The field will be highlighted with a value of XXXX 10 if the server is not present, is congested, or is not correctly configured to respond to Extended (PXE) DHCP Request messages. |
TF-0009 |
Explanation: TFTP block count. The number in hexadecimal of UDP data packets received during the TFTP of the initial bootstrap program. The field will be highlighted with a value of XXXX 10, indicating a general timeout, if the server is not present or is congested. If the field is highlighted with a value of XXXX 3X, check the path and filename of the initial bootstrap program on the server and check if the server's TFTP program is active. |
RS-0040 |
Explanation: Ring status. This field displays a code indicating the status of the network. The field will be highlighted if the operation cannot continue; it will not be highlighted if processing can continue. See Troubleshooting RPL problems. |
PC-4020 |
Explanation: Computer error. This field displays an error code indicating that the adapter has difficulty in functioning with the computer. In most cases, the panel will be frozen and this field will be highlighted because the adapter cannot continue. See Troubleshooting RPL problems. |
AC-0040 0000 0000 0000 |
Explanation: Adapter check. The adapter has detected an internal error and cannot continue. Reboot your computer. If this problem persists, record the adapter check code, and contact your network administrator. |
AE-nnn XX-0011 |
Explanation: Adapter error. The adapter in your computer could not establish communication with the LAN server. The nnn indicates the instance number. The reason for this error is indicated by the XX message to the right of AE-nnn. XX can be either BU or OP. The BU and OP messages are described previously in this section. |
IP-17.17.17.2 |
Explanation: This client's IP address provided by the DHCP server. |
SM-255.255.255.0 |
Explanation: The subnet mask provided by the DHCP server. |
DHCPSvr-10.10.10.3 |
Explanation: IP address of the DHCP server. |
Router-17.17.17.8 |
Explanation: IP address of the router or gateway provided by the DHCP server. |
SR1-0.0.0.0 |
Explanation: IP address of a static route provided by the DHCP server. |
SR2-0.0.0.0 |
Explanation: IP address of a static route provided by the DHCP server. |
BINL-10.10.10.5 |
Explanation: IP address of the Boot Image Negotiation Layer (BINL) service machine. |
BD-0001 |
Explanation: How many boot server requests sent to the boot server. |
BootSrv-10.10.10.4 |
Explanation: IP address of the boot server currently being queried for the initial Network Boot Program (NBP) or the IP address of the boot server providing the credentials for NBP authentication. |
BIS-21 |
Explanation: A highlighted field indicating a Boot Integrity Services error has occurred. |
Select Boot Server 10 |
Explanation: A list of available boot servers. The prompt is displayed followed by the number of seconds remaining before the first item in the boot menu is auto-selected. If a number is not present, there is no timeout. Use the up and down arrow keys to traverse the menu and press enter to select. |
TFTP IP-10.10.10.5 |
Explanation: IP address of the server currently being used to download the initial Network Boot Program (NBP). |
TFTPGW-17.17.17.8 |
Explanation: IP address of the gateway currently being used to download the initial Network Boot Program (NBP). |
If you do not get the expected results when using an RPL feature on a client computer, see Table 1.
If other computers on the network need problem determination, you might need one or more of the following documents:
Table 1. Failure indication messages
Failure Indication | Action |
---|---|
The computer's BASIC panel appears, or the computer boots to the hard disk or diskette drive. | Perform the steps in Installation and configuration. |
The BU field on the client computer display panel is highlighted. | See Bring-up error. |
The OP field on the client computer display panel is highlighted. | See Open error. |
The RS field on the client computer display panel has a value other than zero (0) and is highlighted. | See Ring status error. |
The PC field on the client computer display panel is highlighted or is shown with counters not being updated. | See PC Error. |
The client computer display panel shows any response that has not been identified. | Contact your network administrator. |
The client computer display panel shows that the elapsed
time (ET) field has stopped with only a few seconds of time accumulated, and
the bring-up (BU) error field is highlighted. The RPL feature tried
three times and was unable to initialize the adapter for use. The BU
error codes and the action to take are listed in Table 2.
Table 2. Bring-up error causes and actions
BU Error Code | Cause | Action |
---|---|---|
0020-002F, 0030-003F | A module on the adapter is not responding correctly. | The adapter appears defective. Run the diagnostics. |
0048 | Initialize timeout. | The adapter appears defective. Run the diagnostics. |
All others | Adapter failure | The adapter appears defective. Run the diagnostics. Contact your network administrator if problems persist. |
The open error (OP) field contains an error code. This code might be displayed normally or flashing.
If the error code is flashing, the RPL feature is trying to open the adapter after an unsuccessful attempt.
If the problem persists, record the 4 digits of the flashing OP
field. Using Open Error and the Reason Code as the symptom, refer to
the IBM Token-Ring Network Problem Determination Guide to resolve the problem.
Table 3. Open error causes and actions
OP Error Code | Cause | Action |
---|---|---|
0011, 0010 | No media attached. | Connect the UTP or STP cable to the adapter. |
002D | A client computer is trying to be the first active computer on a token-ring network. | Start your RPL server. If the error persists, reboot the client computer. |
All others | Adapter open failure. | Refer to the IBM Token-Ring Network Problem Determination Guide. |
A ring error was detected when the RPL feature or bootstrap
program was executing. The ring status (RS) error field contains the
error code. Locate the error code in Table 4 to determine the correct action to take. Some values
might be displayed that are a combination of the values listed in the
table. The x's used in the RS Error Code column can be
any hexadecimal number from 0 through F.
Table 4. Ring status error causes and actions
RS Error Code | Cause | Action |
---|---|---|
Cxxx to Dxxx |
| Refer to the IBM Token-Ring Network Problem Determination Guide. |
2000 | This adapter has detected a soft-error condition. | No action required. |
08xx | Wire fault. The adapter has detected a problem in itself or in its lobe. | Refer to the IBM Token-Ring Network Problem Determination Guide. |
04xx | The adapter detected an internal hardware error. | Contact your network administrator. |
x1xx | Remove received. This adapter was removed from the network. | Contact your network administrator for assistance. |
0080 | Counter overflow. One of the error log counters has incremented past 256. | Restart the computer. |
0040 or 0060 | Single station. The adapter has opened and is the only station on the network. This bit resets when another station inserts. | No action is required unless other stations are known to be operating on this network. If other stations are on the network, refer to the IBM Token-Ring Network Problem Determination Guide. |
0020 | Ring recovery. The adapter is transmitting or receiving claim token frames. | No action is required. |
0004 | Full-duplex. The adapter is operating in full-duplex mode. | No action is required. |
All others | Reserved. | Contact your network administrator for assistance. |
The RPL feature has detected a problem with either the software
or hardware in the client computer. Retry the operation by restarting
the computer at least once. If the problem persists, locate the error
code in Table 5 to determine the correct action to take.
Table 5. PC error causes and actions
PC Error Code | Cause | Action |
---|---|---|
05xx | An invalid command control block (CCB) code was issued to the adapter support subset. xx = the CCB code. | Check the bootstrap program if it is user-written. If not, contact your network administrator for assistance. Provide the CCB code. |
06xx (not highlighted) | PROGRAM.ALERT frames being transmitted. The xx
portion of the value represents the alert code.
| Restart the computer. If this error persists, contact your network administrator for assistance. |
07xx | The adapter failed a wrap test. xx = system status block (SSB) return code. | The adapter appears defective. Run the diagnostics. Contact your network administrator if problems persist. |
All others | A computer hardware or software error has occurred. | Perform the computer diagnostic test procedure or contact your network administrator for assistance. |
The IBM Turbo 16/4 Token-Ring PC Card 2 supports RPL from the following servers:
The Remote Program Load (RPL) function enables an adapter to boot a computer using files that the computer receives from a LAN server. The computer that requests these files is referred to as the client computer, and the computer that responds with these files is referred to as the LAN server. In order for RPL to take place, two things must occur. First, the RPL feature of the adapter in the client machine initiates the RPL request. Second, a LAN server responds to the RPL request with the files to bring up, or boot, the client computer.
The following sections are included here:
For the RPL process to begin, the feature must be enabled on the adapter installed in the client computer, and the client computer must recognize the RPL feature of the adapter as the first or only bootable device present.
The adapter is shipped with the RPL feature enabled. To ensure that it is enabled, run the diagnostics and, at the diagnostics test panel, press F5 to view or change the RPL setting.
All IBM PCs support RPL, and many IBM-compatible PCs also do. If your computer is not an IBM PC, refer to your computer user manual or contact the manufacturer if you are not sure whether it supports RPL.
On most IBM PCs you can make this adapter the first bootable, or startup, device by selecting Network as the first startup device in the startup sequence in the configuration utility (usually you enter the configuration utility by pressing F1 when the IBM logo and Configuration Utility program symbol appear during the power-on process). If drive A is the first bootable device, consider making the adapter the second bootable device. Refer to the user manual for your IBM PC if you need further instructions for altering the startup sequence or entering the configuration utility.
After you have successfully selected RPL as the first startup, or bootable, device you will see an RPL panel when your client computer is booting.
+--------------------------------------------------------------------------------+ |IBM Turbo 16/4 T-Ring PC Card RPL v1.01 (980921) | |(C) Copyright 1991-1994 Novell, Inc. All Rights Reserved. | |(C) Copyright 1996 IBM Corp. All Rights Reserved. | | | |RPL-ROM-HSM: 200 BU-0000 | |RPL-ROM-HSM: 201 OP-0000 16 | | | |RPL-ROM-ADR: 0020 3556 6D87 | |RPL-ROM-IRQ: 2 | |RPL-ROM-MM1: D600 | |RPL-ROM-PIO: 0A20 | | | |RPL-ROM-FFC: 01 | |RPL-ROM-SFC: 02 | |RPL-ROM-SEQ: 01 | |RPL-ROM-ERR: | +--------------------------------------------------------------------------------+
This example shows all of the possible error and status message prefixes. You will normally not see the error status condition prefixes, such as RPL-ROM-ERR, unless an error condition occurs. These error and status messages are described in RPL messages.
Please refer to the chapter on Remoteboot in the Microsoft Windows NT Networking Guide for the following features:
At a command prompt on the server, change to the c:\winnt\RPL\bblock\netbeui directory and create a directory named ibmtokcs. Within the ibmtokcs subdirectory create a PROTOCOL.INI file that has the following data in it:
Note: | Even though the DOS device driver file is called IBMTOKCS, the device driver
is known to the operating system as IBMTOK.
[protman] drivername = protman$ dynamic = yes priority = netbeui [netbeui_xif] drivername = netbeui$ bindings = ibmtok_nif names = 6 ncbs = 12 packets = 20 pipeline = 10 sessions = 6 stacksize = 512 lanabase = 0 [xnsnb_xif] drivername = xnsnb$ bindings = ibmtok_nif load = xnsnb[cbr] lanabase = 1 [xnstp_xif] drivername = xnstp$ bindings = ibmtok_nif load = xnstp[ub] lanabase = 1 [tcpip_xif] drivername = TCPIP$ disabledhcp = (TCPIP_NO_DHCP) ipaddress0 = (TCPIP_ADDRESS) subnetmask0 = (TCPIP_SUBMASK) defaultgateway0 = (TCPIP_GATEWAY) tcpsegmentsize = 1450 tcpwindowsize = 1450 nbsessions = 6 load = tcptsr[c],tinyrfc[c],emsbfr[cr] unload = "unloadt /notsr[dc]" bindings = ibmtok_nif lanabase = 1 [ipx_xif] drivername = ipx$ load = ipxmark[u],ipx[u] unload = ipxrel[c] bindings = ibmtok_nif lanabase = 1 [msdlc_xif] drivername = msdlc$ bindings = ibmtok_nif load = msdlc[ub] unload = msdlc[u] [ibmtok_nif] drivername = ibmtok$ MaxTransmits = 2 MaxTxFrameSize = 2048 MinRcvBuffs = 8 RcvBuffSize = 1120 |
Also, within that same subdirectory ibmtokcs create a DOSBB.CNF file that has the following data in it.
;DOS RPL with IBM Turbo 16/4 Token-Ring Adapter BASE 1A0H RPL BBLOCK\RPLBOOT.SYS LDR BBLOCK\RPLSTART.COM ~ DAT BBLOCK\NETBEUI\IBMTOKCS\PROTOCOL.INI ;DAT BBLOCK\NDIS\IBMTOKCS\LA1.MSG DRV BBLOCK\RPLDISK.SYS ~ ~ ~ EXE BBLOCK\RPLPRO1.COM ~ 2 ~ EXE BBLOCK\I13.COM ~ ~ ~ EXE BBLOCK\RPLBIND2.EXE ~ ~ EXE BBLOCK\PROTMAN.EXE ~ ~ EXE BBLOCK\RPLBIND1.EXE ~ ~ ;DRV BBLOCK\IPXNDIS.DOS ~ ~ ~ ;DRV BBLOCK\TCPDRV.DOS /IDOS ~ ~ EXE BBLOCK\NETBEUI\NETBEUI.EXE ~ 10 ~ DRV BBLOCK\NDIS\IBMTOKCS.DOS DRV BBLOCK\PROTMAN.DOS /IDOS ~ M
Go to http://www.ibm.com/networking/support
and download the IBM Turbo 16/4 Token-Ring Adapter driver diskette.
Copy the following files from the DOS directory (a:\dos) to
c:\winnt\rpl\bblock\ndis:
IBMTOKCS.DOS
LA1.MSG
The Windows NT 4.0 Server support for RPL does not include the image for IBM DOS.
Note: | If the DOS image is already on the server, skip to Creating Remoteboot configurations for the IBM Turbo 16/4 Token-Ring Adapter. |
Copy c:\dos\*.* v:\binfiles\dos700 Attrib -s -h c:\io.sys Attrib -s -h c:\msdos.sys Copy c:\io.sys v:\binfiles\dos700 Copy c:\msdos.sys v:\binfiles\dos700 Attrib +s +h c:\io.sys Attrib +s +h c:\msdos.sys
From a Windows NT 4.0 Remoteboot server command prompt, run RPLCMD.EXE. This utility allows you to add boot block records for the adapter and vendor ID. Follow the illustration below to set up and configure a boot image for your adapter.
c:\> rplcmd Adapter Boot Config Profile Service Vendor Wksta [Quit]: b Add Del Enum: a BootName=DOS700 **rpl client environment** VendorName=002035 **the first 6 digits of the adapter's hexadecimal MAC address** BbcFile=BBLOCK\NETBEUI\IBMTOKCS\DOSBB.CNF All other parameters are optional BootComment=DOS 700 IBM TURBO 16/4 TOKEN RING WindowSize=0 Adapter Boot Config Profile Service Vendor Wksta [Quit]: v Add Del Enum: a VendorName=002035 **the first 6 digits of the adapter's hexadecimal MAC address** VendorComment=DOS 700 IBM TURBO 16/4 TOKEN RING Adapter Boot Config Profile Service Vendor Wksta [Quit]: c Add Del Enum: a ConfigName=DOS700C BootName=DOS700 DirName=DOS DirName2= FitShared=fits\dos700.fit FitPersonal=fits\dos700p.fit All other parameters are optional ConfigComment=DOS 700 IBM TURBO 16/4 TOKEN RING ** shown in step 4 below ** DirName3= DirName4= Adapter Boot Config Profile Service Vendor Wksta [Quit]: q
RPL-ROM-HSM: BU-0000 |
Explanation: Bring-Up. This field is displayed as X'0000' if the adapter has been successfully initialized. If not, a code other than X'0000' is displayed and the field is highlighted. See Troubleshooting RPL problems. |
RPL-ROM-HSM: OP-0000 16 |
Explanation: Open Return Code. The first 4 digits are X'0000' and the last 2 digits identify the adapter data rate, if the adapter has been successfully opened and attached to the network. If not, a code other than X'0000' is displayed and the field is flashing. See Troubleshooting RPL problems. |
RPL-ROM-ADR: 0020 3556 6D87 |
Explanation: Adapter Address. The permanently encoded address of the token-ring adapter in your computer. This address is always 12 hexadecimal characters (6 bytes) long. |
RPL-ROM-IRQ: 2 |
Explanation: Interrupt. The system interrupt level that the adapter currently occupies. |
RPL-ROM-MM1: D600 |
Explanation: Memory (read-only memory). Segment address in memory where BIOS has mapped the RPL ROM code. |
RPL-ROM-MM2: D800 |
Explanation: Memory (random-access memory). Segment address in memory where BIOS has mapped the token-ring adapter's RAM. |
RPL-ROM-PIO: 0A20 |
Explanation: System I/O address. The I/O address that the adapter currently occupies in the system. |
RPL-ROM-FFC: 01 |
Explanation: Request Count (FIND Frame Count). The number (in hexadecimal) of FIND frames that have been transmitted. An excessive request count indicates that the LAN server is not present, is congested, or is not correctly configured to RPL this adapter. |
RPL-ROM-SFC: 02 |
Explanation: SEND.FILE.REQUEST Frame Count. The number of SEND.FILE.REQUEST frames that have been transmitted. An excessive SEND.FILE.REQUEST frame count indicates that the LAN server is not responding after having been found. |
RPL-ROM-SEQ: 01 |
Explanation: File Response Sequence Number. This value is displayed when the LAN server has responded to the SEND.FILE.REQUEST. It indicates how many times valid FILE.DATA.RESPONSE frames have been received. |
RPL-ROM-ERR: |
Explanation: Computer error. This field displays an error code indicating that the adapter has difficulty in functioning with the computer. In most cases, the panel will be frozen and this field will be highlighted because the adapter cannot continue. See Troubleshooting RPL problems. |
The following chart is helpful if you do not get the expected results when you use an RPL feature on a client computer.
If other computers on the network need problem determination, you might need one or more of the following documents:
Table 6. Failure indication messages
Failure Indication | Action |
---|---|
The computer's BASIC panel appears, or the computer shows a diagram to insert a diskette into the diskette drive, or boots to the hard disk or diskette drive. | Perform the installation steps for your adapter. |
The BU field on the client computer display panel is not X'0000'. | See Bring-up error. |
The OP field on the client computer display panel is not X'0000'. | See Open error. |
The Client computer display panel shows any response that has not been identified. | Contact your network administrator. |
The bring-up (BU) field is not X'0000'. The
RPL feature is unable to initialize the adapter for use. The BU error
codes and the action to take are listed here:
BU Error Code | Cause | Action |
---|---|---|
0020-002C | A module on the adapter is not responding correctly. | The adapter appears to be defective. Run the adapter diagnostics. |
0048 | Initialization timeout. | The adapter appears to be defective. Run the adapter diagnostics. |
All others. | Adapter failure. | The adapter appears to be defective. Run the adapter diagnostics. Contact your network administrator if problems persist. |
The open error (OP) field contains an error code.
If the OP field is not X'0000', the RPL feature is trying to open the
adapter after an unsuccessful attempt. If the problem persists, record
the 4 digits of the OP field. Using Open Error and the Reason Code as
the symptom, refer to the IBM Token-Ring Network Problem Determination
Guide to resolve the problem.
OP Error Code | Cause | Action |
---|---|---|
0011, 0010 | No media attached. | Connect the cable to the adapter or to the token-ring concentrator or both. |
002D | The adapter detected that it was the only adapter present in the ring during the open command it it has removed itself from the ring. | Start your RPL server. If the error persists, reboot the client computer. |
002E | The adapter could not detect frames during the open command and has removed itself from the ring. This indicates that either the adapter is running at the wrong speed and does not have circuitry to detect it, or there is something wrong with the access unit or cabling to which the adapter is connected. | Connect the cable to the adapter or to the token-ring concentrator or both. Check if you are using the correct cable. |
All Others | Adapter open failure. | Refer to the IBM Token-Ring Network Problem Determination Guide. |
This chapter describes the IBM LAN Client features.
This section lists the adapters, software, and operating systems supported by the IBM LAN Client.
IBM LAN Client provides support for the following adapters:
The device driver needed for the adapter to operate with the IBM LAN Client software is provided on the adapter product CD-ROM. The following drivers are provided:
The installation program will copy the driver to your workstation hard disk when you tell it which adapter you will be using. It will also provide the correct load statements in STARTNET.BAT.
IBM LAN Client provides support for the following protocols and client applications:
For DOS 5.0 or later:
For Windows 3.1, Windows 3.11, and Windows for Workgroups 3.11:
Note: | IBM LAN Station Manager cannot be run in the same workstation as IBM LAN Client. |
IBM LAN Client supports the following desktop operating systems:
The following restrictions apply for this release of IBM LAN Client:
IBM LAN Client provides program interfaces to support network application programs using selected IBM Token-Ring adapters. It allows a DOS/Windows client workstation to communicate with an IBM LAN Server at Version 3.0, 4.0, and Warp Server, or with a Novell NetWare Server at Version 2.15c or later, or to use TCP/IP applications in Windows. (The IBM and Novell client code is included with this package but, with the exception of PING, TCP/IP applications are not.) In addition, support is provided for programs written to the NetBIOS or IEEE 802.2 application programming interfaces.
IBM LAN Client minimizes the use of DOS conventional memory for network
communications. With LAN Client, the LAN adapter drivers and protocol
stacks no longer require large amounts of DOS memory. Table 9 shows the memory requirements LAN Client, compared with
existing implementations. This table shows how much DOS conventional
memory is used by LAN Client for three popular communication protocols,
compared with current usage.
Table 9. Memory reduction when using LAN Client
Protocol | Before IBM LAN Client | With IBM LAN Client |
---|---|---|
IPX | 59 KB | 5 KB |
IEEE 802.2 | 95 KB | 4 KB |
NetBIOS | 95 KB | 4 KB |
Note: | To install LCINST to a hard disk from the LAN Client diskettes, insert LAN Client diskette 1 in drive A and enter install. |
Note: | The command line version (LCINSTC.EXE) can also be used to install IBM LAN Client. For a list of valid parameters that can be used with the command line version, type lcinstc /h and press Enter. |
This chapter describes the features of the IBM LAN Adapter Management Agent.
The IBM LAN Adapter Management Agent supports any IBM LAN adapter with a device driver for the operating systems listed in the following section. The latest LAN adapter drivers provide the most manageability of the LAN adapter.
For Windows environments, the Agent requires that Windows NT Workstation or Windows NT Server Version 3.51 or later, Windows 95, Windows 98, or Windows 2000 be installed on the system. The Agent implements Desktop Management Interface (DMI) Version 2.0 on Windows NT, Windows 95, Windows 98, and Windows 2000. Windows environments support SNMP Version 1.
For OS/2 environments, the Agent requires that OS/2 Version 3.0 or later be installed on the system. The Agent implements DMI version 1.0 on OS/2. OS/2 environments support SNMP Version 2.
The IBM LAN Adapter Management Agent makes IBM LAN adapters visible to management applications using industry-standard management techniques. The Agent provides manageability using either the Simple Network Management Protocol (SNMP) or the DMI.
SNMP is the most common management-oriented protocol. The IBM LAN Adapter Management Agent can be coupled with IBM Nways(R) Management Applications to remotely manage IBM LAN adapters resident in the Agent's workstation. The Agent can generally be managed by any SNMP-compliant management application.
DMI is a programming interface developed by members of the PC industry to bring management and control to PC systems. DMI browsers, which are supplied in the Agent package, can also manage other systems using standard communications protocols. DMI is also used by many workgroup management applications.
The Agent runs on Microsoft Windows NT, Windows 95, Windows 98, Windows 2000, and IBM OS/2 workstations and provides an easy-to-use installation process for each environment. Management using SNMP and DMI is available for each operating environment. Some of the attributes provided by the Agent are:
The IBM LAN Adapter Management Agent allows you to manage the LAN adapters in PC systems.
Before you can install the SNMP function of the IBM LAN Adapter Management Agent on Windows platforms, the SNMP Service must already be installed at the Agent's station. This is because the Agent needs to add entries to the SNMP Service registry parameters. The SNMP Service enables a Windows end station to be administered remotely with an SNMP management tool. The DMI function of the Agent has no installation prerequisites for Windows NT, Windows 95, Windows 98, and Windows 2000.
The Agent requires that TCP/IP for OS/2 Version 3.0 or later be installed on the OS/2 system.
Web-based device management using Java(R) technology is provided by coupling the Agent and IBM Nways Management Applications. A LAN adapter management application is provided by:
To install the IBM LAN Adapter Management Agent, run the SETUP.EXE program from a diskette, or execute the appropriate self-extracting installation package. The following major components are installed:
The DMI service provider and the DMI instrumentation are installed as Windows Services. On Windows NT, they are originally given a Startup Type of Automatic. On Windows 95 and Windows 98, they are started in the RunServices registry key. The DMI service provider has the service name Win32sl. The SNMP extension agent is used in conjunction with Microsoft's SNMP extensible agent service to provide a mapping between SNMP and DMI. The DMI Browser application provided is the Intel DMI Explorer. The DMI browser application, this document, and a deinstall icon are contained in the IBM LAN Adapter Management Agent folder.
To install the Agent, run the INSTALL.EXE program from the installation media. The following components are installed:
For OS/2 Version 3.0, the DMI service provider and the DMI instrumentation are started automatically by commands in CONFIG.SYS. The DMI-to-SNMP mapper (DMISA.EXE) and SNMP daemon (SNMPD.EXE) start automatically from the system's Startup folder. To start the DMI browser, double-click the icon in the IBM LAN Adapter Management Agent for OS/2 folder.
If you have previously installed the SystemView(R) Agent for OS/2 on your OS/2 Version 3.0 workstation, some of the SNMP and DMI management components will already exist. The DMI service provider is started automatically in CONFIG.SYS. The DMI-to-SNMP mapper (DMISA.EXE) and SNMP daemon (SNMPD.EXE) start automatically from the System Startup folder. To start the DMI browser, double-click the icon in the SystemView Agent for OS/2 folder. The DMI instrumentation for IBM LAN adapters is provided by the INSTALL program and configured to start automatically from CONFIG.SYS.
For OS/2 Version 4.0, some of the SNMP and DMI management components are already provided by the base operating system. The DMI service provider is always running. The DMI-to-SNMP mapper, SNMP daemon, and DMI browser are part of the System Management Agent folder, in the Utility program folder. The System Management Agent folder provides separate icons for startup and configuration of the System Management Agent. The DMI instrumentation for IBM LAN adapters is provided by the INSTALL program and is configured to start automatically from CONFIG.SYS.
The IBM LAN Adapter Management Agent for OS/2 folder will always include this document and a deinstall icon.
If you alter the adapter configuration in your OS/2 system, you can use the MPTS Configuration program to bind the IBM LAN Adapter Management Agent for OS/2 to the LAN adapters of your choice. Go into the Adapter and Protocol Configuration menu and add the IBM LAN Adapter Management Agent for OS/2 for the adapters that you want to manage.
Remote DMI allows the DMI Browser to manage IBM LAN adapters in other PC systems. Remote DMI exists only with DMI Version 2.0. The DMI Browser must be started with command line parameters for Remote DMI. The underlying distribution mechanism for Remote DMI is the Remote Procedure Call Network Service. The functionality of Remote DMI is contained in the DMI Browser (IDMIEX.EXE) and the DMI Service Provider (WIN32SL.EXE). To use Remote DMI, configure the Remote Procedure Call (RPC) Network Service and then start the DMI Browser with the appropriate command line parameters.
The Properties are:
idmiex /path "dce|tcpip|hostname"
Some specific examples are:
idmiex /path "dce|tcpip|9.37.233.1" idmiex /path "dce|tcpip|server99"
Note: | The DMI Browser in the Agent pulldown menu will manage the local system. |
When you use an SNMP-based manager and its MIB browser, the general steps are:
iso.org.dod.internet.private.enterprises.ibm.ibmArchitecture.ibmDmi. mibsFromMifs.ibmLanAdapter.dmtfGroups
or
1.3.6.1.4.1.2.5.11.1.8.1
This chapter describes the Route Switching feature of the IBM token-ring adapters.
| Windows NT 3.51, 4.0 | Windows 95, 98, 2000 | Windows 3.x | OS/2 Warp 3.0 and later | Novell NetWare Server |
---|---|---|---|---|---|
IBM 16/4 Token-Ring CardBus Adapter | Supported (Windows NT 4.0 only) | Supported | Not supported | Supported | Not supported |
IBM 16/4 Token-Ring Low Profile PCI Management Adapter | Supported (Windows NT 4.0 only) | Supported (Windows 98 and Windows 2000 only) | Not supported | Not supported | Not supported |
IBM High-Speed 100/16/4 Token-Ring PCI Management Adapter | Supported | Supported | Not supported | Supported | Supported |
IBM 16/4 Token-Ring PCI Management Adapter | |||||
IBM High-Speed 100/16/4 Token-Ring PCI Adapter | Supported | Supported | Supported (using LAN Client) | Supported | Supported |
IBM 16/4 Token-Ring PCI Adapter 2 | |||||
IBM 16/4 Token-Ring PCI Adapter 2 with Wake on LAN | |||||
IBM PCI Token-Ring Adapter | |||||
IBM PCI Wake on LAN Token-Ring Adapter | |||||
IBM Turbo 16/4 Token-Ring ISA Adapter | Supported (client mode only) | Not supported | Not supported | Not Supported | Supported (client mode only) |
IBM Auto-Wake 16/4 Token-Ring ISA Adapter | |||||
IBM Turbo 16/4 Token-Ring PC Card | Supported | Supported | Not supported | Not supported | Supported |
IBM Turbo 16/4 Token-Ring PC Card 2 |
Before the explosive growth in the use of Internet-based protocols, the 80/20 rule was followed when designing and deploying an IP-based network. This rule stated that the network should be designed on the assumption that 80% of network traffic would remain within the same subnet while 20% of network traffic would cross subnet boundaries. Maintaining the 80/20 rule allowed routers of that time to keep up with traffic flowing between subnets. With the explosive growth of the use of HTTP, that is, Web-based intranets and the Internet, the 80/20 rule can no longer be maintained.
As users jump from server to server on the Web they might jump from subnet to subnet, requiring almost all network activity to traverse the routers dividing the subnets. In addition, as network backbone technologies increase in speed, such as the move to 100-Mbps Token-Ring, the router bottleneck problem becomes even more of an issue.
Campus network architectures have been moving in two fundamental directions. The first is a continuation of a core networking architecture, with routers moving data between subnets, and the second is an edge networking architecture such as the IBM Switched Virtual Networking framework. In the area of performance improvements, efforts in the core networking model center around improving router performance, for example the recent interest in media-speed routers. By contrast, one of the main interests of the edge networking model is based on improving networking performance by distributing function away from a centralized, single-point-of-failure device.
Route Switching is IBM's approach to IP switching, or Layer 3 switching, that is actually a hybrid of both models. Route Switching still requires a centralized routing function in the network in order to provide the many functions that a router provides, except for the movement of traffic between subnets. With Route Switching, the traffic movement more closely follows the edge networking model.
The Route Switching feature of the IBM Token-Ring Adapters has been integrated within the device driver making installation and configuration as simple as upgrading the device driver. There are two modes of operation for Route Switching: client mode or peer mode. Client mode is the preferred mode. Route Switching is based on the Next Hop Routing Protocol (NHRP) standard from the Internet Engineering Task Force (IETF) and makes use of this standard when operating in either client or peer mode.
When Route Switching is operating in client mode an IBM Multiprotocol Switching Services (MSS) Server is required to perform the Route Switching server function. When in client mode, the enabled IP host issues requests to the IBM MSS Server for shortcut information for a remote IP host to which it is attempting to communicate. Once the shortcut information is received by the requesting client, subsequent traffic to the remote IP host is sent through the shortcut path instead of through the routed path. When Route Switching is operating in peer mode, the same request for shortcut information is sent directly through the routers to the remote IP host. If you install and configure Route Switching for peer mode on the remote host, the remote host sends a shortcut reply back to the requesting host. In either case, until the reply is received, the IP traffic will continue to be sent on the routed path.
In both situations, access control maintained by the router is not compromised. In the case of client mode, the MSS is also performing the routing function and will ensure that shortcut information is not supplied for a remote host that is not allowed to be reached. When in peer mode, the shortcut request goes through the router to the remote host. Therefore, if the requesting host is not permitted to communicate with the remote host, the request for a shortcut path will never be received by the remote host.
Route Switching can also be set to automatic mode. When in automatic mode Route Switching will initially operate in both client and peer mode. The first reply to a shortcut request that the host receives will determine the permanent mode of operation. For example, as soon as the adapter opens, Route Switching will begin attempting to discover the MSS Servers that exist in the network. At the same time, if IP traffic is being transmitted that is destined to a remote host not in this subnet, Route Switching will also begin sending shortcut requests to these remote IP hosts. If the requesting host receives a server discovery reply from an MSS Server, Route Switching will transition into client mode. If it receives a reply from a remote IP host, it will transition into peer mode.
Route Switching can greatly improve performance of IP-based communications in networks with congested routers. The goal of Route Switching is to bypass the routing functions in an IP-based network without bypassing or undermining the other functions that a router provides, such as a firewall function and possibly broadcast containment. If the routers are creating a delay in the communication between IP hosts, Route Switching will eliminate that delay with just a simple upgrade of the LAN adapter device driver.
If a network currently has routing functions that are in need of performance improvements, Route Switching can add life to these routers and extend their usefulness indefinitely. In other words, with just the simple upgrade of device drivers for the IBM Token-Ring adapters, huge expenses for new higher performance routers can be deferred or completely eliminated.
An environment in which Route Switching can be useful is a premise, or one-armed router, configuration. In this configuration there is one router at a location managing a multiple IP subnet network. All IP traffic between hosts on different subnets must go through this router. In this situation, two workstations might be on the same physical token ring, but from an IP perspective are configured to be on different IP subnets. This is very often the case when the two hosts belong to different business organizations or due simply to when they were installed. In this situation, traffic between these two workstations must leave one workstation, traverse the network all the way to the router, through the router, and then back across the network to the other workstation.
With Route Switching configured for peer mode, only the initial IP packets between these two hosts will be sent through the router. If in fact the two workstations are on the same ring, once the Route Switching function in the two workstations exchange their shortcut information, the traffic will only exist on that ring and will not be forwarded across any bridging functions. Suddenly, performance between these workstations is tremendously improved due to the removal of the router from the communications path. Also, the total number of packets flowing in the network is greatly reduced as well as the work load on the overburdened router.
View the following values for the current configuration as well as the current status of Route Switching while using the IBM LAN Adapter Management Agent.
Route Switching Mode (Win32 only) Indicates the current state of the Route Switching function.
MSS Server Count Valid when Route Switching is operating in client mode. MSS Server count indicates the number of MSS Server interfaces that have responded to the request made by this computer to determine the Route Switching Servers in the network.
Maximum number of Cache Entries States the maximum number of cache entries available for use.
Current Number of Active Cache Entries Indicates the number of cache entries that are currently in use and contain valid shortcut information.
Switched Frame Count Count of the frames which have been sent using shortcut information when they otherwise would have been sent through a routed path. Observing this value changing over time indicates that Route Switching is operating.
Peer Holding Time (Win32 only) Valid when Route Switching is operating in peer or auto mode. Peer holding time indicates the cache entry holding time value which has been configured. This value is passed by this machine in replies to shortcut information.
When Route Switching is operating in peer mode there are two requirements. First, IP hosts communicating with each other must have a Route Switching-enabled device driver installed and have Route Switching configured to either peer or auto mode. Second, there must be a Layer 2 path between the IP subnets.
The client mode of operation is an asymmetric solution in terms of the two IP hosts communicating. This means that Route Switching Client can be configured on only one of the two hosts and benefits can be achieved. In order for Route Switching Client to operate, an IBM MSS properly configured for Route Switching is required.
For more information about MSS, go to http://www.ibm.com/networking.
Installation and configuration information are particular to each adapter and are explained in the installation guide for your adapter. Go to http://www.ibm.com/networking and view the installation books for your adapter.
The Route Switching function operates exactly the same way in every environment and accepts the same parameters in every environment. The following four parameters are used by the Route Switching function:
This parameter defines the mode in which the Route Switching function will operate. Route Switching can operate in client, peer, and auto modes, or it can be disabled.
In client mode, Route Switching will operate with an IBM MSS Server to provide the Route Switching function. In this mode of operation, the endstations will make requests of the server for shortcut information to remote IP hosts with which it is communicating.
In peer mode, Route Switching will operate without the existence of an IBM MSS Server. In this mode of operation, the end stations will make requests to the remote IP hosts to which it is communicating for its shortcut information. This mode of operation requires both IP host end stations involved in a conversation to have Route Switching Peer correctly installed and configured in order to operate. When in peer mode, the IP subnet mask must be passed to the Route Switching function.
In auto mode, Route Switching will initially operate in both modes. This means it will attempt to find an IBM MSS Server in the network as well as remote IP host end stations configured with Route Switching Peer. The first positive response it receives will determine the mode of operation of Route Switching for this end station.
For example, if an end station begins to operate in auto mode it will begin to attempt to discover IBM MSS Servers in the network. When IP traffic is transmitted to remote IP hosts residing on a different subnet, the Route Switching function will also send a shortcut request to the remote host in order to determine the shortcut information. If the remote host has configured Route Switching to peer or auto mode, it will respond to the request. If there are no IBM MSS Servers in the network, the end station will then enter into peer mode of operation. When in auto mode, the IP subnet mask must be passed to the Route Switching function.
If the machine is placed into a reduced-power state or is in some way suspended when configured in auto mode, it will return to auto mode when it returns to full power. This allows Route Switching to handle the changing of the network while an end station is not on the network.
This parameter is required when Route Switching is operating in either peer or auto mode. It defines the IP subnet mask to which this adapter is connecting. This parameter is typically determined automatically. The Route Switching IP Subnet Mask must be in IP dotted-decimal address notation.
This parameter is used when Route Switching is operating in either peer or auto mode. This value defines the amount of time that shortcut information is considered to be valid by the Route Switching function. When an end station provides its shortcut information to another requesting end station it includes this value along with the information. The requesting end station is allowed to use this shortcut information for this specified amount of time.
This parameter specifies the maximum number of entries that the Route Switching function can maintain at any given moment in time.
Each of the following installation and configuration sections assumes that your adapter is already installed and configured. The following sections define the steps required to enable Route Switching. If the adapter is not yet installed, refer to the Installation and Configuration manual for the adapter being used.
If you are using a Token-Ring PCI adapter on Windows 95 OSR2, Windows 98, Windows NT, or Windows 2000, use the instructions in Token-Ring PCI adapters (on Windows 95 OSR2, Windows 98, Windows NT, and Windows 2000) to set Route Switching parameters.
If you are using the IBM Turbo 16/4 Token-Ring PC Card 2, use the instructions in IBM Turbo 16/4 Token-Ring PC Card 2 to set Route Switching parameters.
Otherwise, use the instructions in this section.
To set the Route Switching parameters, perform the following steps:
To set the Route Switching parameters, perform the following steps:
To set the Route Switching parameters, perform the following steps:
To set the Route Switching parameters, perform the following steps:
For Route Switching configuration:
To set the Route Switching parameters, perform the following steps:
Note: | To install LCINST.EXE to a hard disk from the LAN Client diskettes, insert LAN Client diskette 1 in drive A and enter install. |
Note: | If you select Auto or Peer, then you must enter an IP Address and a Subnet Mask on the TCP/IP configuration panel. You cannot enable DHCP. |
Note: | Holding Time is not valid if you selected client mode. |
To set the Route Switching parameters perform the following steps:
This chapter describes the Class of Service (CoS) for IP feature.
CoS for IP is supported for the adapters and operating systems listed
in the following table.
| Windows NT 3.51, 4.0 | Windows 95, 98, 2000 | Windows 3.x (using IBM LAN Client) | OS/2 Warp 3.0 and later | Novell NetWare Server (4.11 and higher) |
---|---|---|---|---|---|
IBM 16/4 Token-Ring CardBus Adapter | Supported (Windows NT 4.0 only) | Supported | Not supported | Supported | Not supported |
IBM 16/4 Token-Ring Low Profile PCI Management Adapter | Supported (Windows NT 4.0 only) | Supported (Windows 98 and Windows 2000 only) | Not supported | Not supported | Not supported |
IBM High-Speed 100/16/4 Token-Ring PCI Management Adapter | Supported | Supported | Not supported | Supported | Supported |
IBM 16/4 Token-Ring PCI Management Adapter | |||||
IBM High-Speed 100/16/4 Token-Ring PCI Adapter | Supported | Supported | Supported | Supported | Supported |
IBM 16/4 Token-Ring PCI Adapter 2 | |||||
IBM 16/4 Token-Ring PCI Adapter 2 with Wake on LAN | |||||
IBM PCI Token-Ring Adapter | |||||
IBM PCI Wake on LAN Token-Ring Adapter | |||||
IBM Turbo 16/4 Token-Ring PC Card | Supported | Supported | Not supported | Not supported | Supported |
IBM Turbo 16/4 Token-Ring PC Card 2 |
Special note regarding token-ring PCI adapters
The IBM token-ring PCI adapters are enabled with advanced technology that lets higher-priority traffic expedite through the adapter, thus preventing this traffic from being held up behind lower-priority traffic.
The adapter includes multiple transmit paths for use by the device drivers. This multiple transmit path capability lets the driver pass a high-priority frame to the adapter and have this frame transmitted before a previously queued normal priority frame. This eliminates any traffic delays for the high-priority traffic from the moment the traffic is deemed to be high-priority in the device driver.
This advanced function exists in all IBM token-ring PCI adapters.
The ability to assign relative priorities, or degrees of importance, to traffic as it traverses a network has existed in token-ring networks since the inception of the token-ring standard. Unfortunately, there has never been a method to assign the priorities to the traffic as the frames were transmitted. CoS for IP solves this problem by allowing network managers to assign priorities to IP traffic transmitted by an IP host.
With the use of CoS for IP, you can categorize your IP traffic on the network and assign a degree of importance in the network to certain types of IP traffic. This prevents traffic considered to be of low importance from taking valuable network bandwidth away from important traffic. The backing up of a server farm or a session of a computer game will no longer adversely impact the streaming of an educational video session or a real-time video conference.
CoS for IP makes use of a traffic prioritization mechanism that has always existed in the token-ring architecture but has never been exploited by higher-layer protocols and applications. CoS for IP does not rely on any special enablement to the infrastructure of the network. That is, the switches and bridges of the network do not necessarily need to know that CoS for IP is being used. Even though the network is not aware of this traffic prioritization mechanism, CoS for IP allows the traffic that has been assigned a high priority to maintain this high-priority status from the time that the traffic enters the network to its final destination.
In addition, CoS for IP does not require new protocol stacks and applications that are aware of traffic prioritization. In fact, the traffic being treated as high priority is up to the network manager and does not even have to be multimedia related. If performing a backup of a server is considered a high priority then this traffic can be deemed more important by the network manager than other traffic on the network.
Because CoS for IP uses a token-ring mechanism for implementing traffic prioritization, the best results occur when the traffic that has been given a priority status is sent through a Layer 2 switched, or bridged, path and travels entirely on token-ring networks. IBM's Route Switching function solves this requirement by establishing the Layer 2 path even when the two end stations reside on different subnets. With the advent of Web-based networking and intranet-based IP networks, intersubnet communications is becoming more the normal situation. Route Switching and CoS for IP work together to resolve growing network performance problems not just for high-priority traffic but for all traffic in the network.
CoS for IP can be used to ensure that time-sensitive traffic, such as streaming audio or video, arrives at the destination computer within the required time. To make use of CoS for IP, a network manager would determine the protocol and the port range being used by the server application and configure CoS for IP with these values on the server. For example, a network manager might have a server running a RealNetworks streaming audio server application that is sending audio traffic to clients using UDP port ranges, 26992 through 29040. The network manager would configure CoS for IP for these values and assign a priority level for this range.
CoS for IP can be managed using LAN Adapter Management Agent. The following values can be displayed:.
LAN Adapter Transmit Priority Information Displays the general transmit priority capabilities of the adapter. For example, this attribute displays the number of physical transmit channels supported by the adapter hardware.
LAN Adapter Transmit Priority Distribution Shows the frame count and byte count for each priority level. Displaying these values will indicate the priority at which traffic is being sent.
LAN Adapter Class of Service Information Displays the number of port ranges defined for each protocol.
LAN Adapter Class of Service TCP Port Ranges Displays each of the defined port ranges for the TCP protocol. Displaying these values will confirm that the port ranges configured have been accepted and are being used by the CoS for IP support.
LAN Adapter Class of Service UDP Port Ranges Displays each of the defined port ranges for the UDP protocol. Displaying these values will confirm that the port ranges configured have been accepted and are being used by the CoS for IP support.
There are no special requirements for the machines that will make use of CoS for IP other than having a supported IBM adapter and the correct level of device driver.
CoS for IP makes use of the priority bits defined by the token-ring architecture. Because of the use of these Layer 2 bit fields, traffic being assigned a higher-than-normal priority should be traversing only a Layer 2 path in order to achieve the full effects of CoS for IP. Route Switching complements CoS for IP by attempting to establish a Layer 2 connection for all IP traffic that would otherwise traverse Layer 3 devices.
Installation and configuration information are particular to each adapter and are explained in the installation guide for your adapter. Go to http://www.ibm.com/networking and view the installation books for your adapter.
CoS for IP uses the destination port number of outbound TCP and UDP traffic to determine the Class of Service, or priority, of the traffic. Once the range of port numbers used for a particular TCP- or UDP-based application has been determined, this port range is simply passed to the CoS for IP function within the device driver through the following configuration parameters.
CoS for IP is enabled in the device drivers by simply defining one or more TCP or UDP port ranges. A port range is defined by a starting port value and an ending port value. Each of these values is inclusive, meaning the port values that make up a port range include the starting and ending values. For each port range defined, you must select a priority value from 1 to 6. You can define a maximum of 15 port ranges for each of the two protocols. When configuring CoS for IP in either the OS/2 or Novell Server environments, define these port range parameters in the following format:
ParmValue := <PortRange>[<PortRange><PortRange>] PortRange := <PortNumber><PortNumber><PriorityValue> PortNumber := a 4-character hexadecimal value. PriorityValue := a 1-character value from 1 to 6.
A bridging device in a token-ring network will forward traffic at a priority of 4 when necessary. If CoS for IP is being used in a network made up of bridges this fact must be taken into account. It might be necessary to make use of only priorities 5 and 6 when defining port ranges in order to keep the traffic at a higher priority than the bridged traffic. When the higher-priority traffic travels across a bridging function the bridge should maintain the frame priority. For example, a network manager has defined certain UDP traffic to be priority 6 and this traffic is to flow across a number of bridges as it travels from a server to a client. When this traffic is forwarded onto subsequent rings by the bridges, the bridges will now forward it with a priority of 6 instead of 4.
Each of the following installation and configuration sections assumes that the adapter is already installed and configured. The following sections define only the steps required to enable CoS for IP. If the adapter is not installed, refer to the installation manual for the adapter you are using.
If you are using a token-ring PCI adapter on Windows 95 OSR2, Windows 98, Windows NT, or Windows 2000, use the instructions in Token-ring PCI adapters (on Windows 95 OSR2, Windows 98, Windows NT, and Windows 2000) to set CoS for IP parameters.
If you are using the IBM Turbo 16/4 Token-Ring PC Card 2, use the instructions in IBM Turbo 16/4 Token-Ring PC Card 2 to set CoS for IP parameters.
Otherwise, use the instructions in this section.
To set the CoS for IP parameters, perform the following steps:
Note: | Class of Service for IP supports a maximum of 15 defined port ranges for each protocol. |
To set the CoS for IP parameters, perform the following steps:
Note: | Class of Service for IP supports a maximum of 15 defined port ranges for each protocol. |
To set the CoS for IP parameters, perform the following steps:
Note: | Class of Service for IP supports a maximum of 15 defined port ranges for each protocol. |
To set the CoS for IP parameters, perform the following steps:
For Class of Service configuration:
To set the CoS for IP parameters, perform the following steps:
Note: | To install LCINST.EXE to a hard disk from the LAN Client diskettes, insert LAN Client diskette 1 in drive A and enter install. |
To set the CoS for IP parameters, perform the following steps:
This chapter describes the Redundant NIC feature.
Redundant NIC is currently supported on the following adapters:
The following operating environments are supported:
Quick Failover, an extension to Redundant NIC, is available for the following adapter and microcode combinations on Windows NT 4.0 SP5, NetWare 4.11 and 4.2 with IWSP6A and NetWare 5.0 with NW5SP2A.
Adapter | Microcode |
IBM High-Speed 100/16/4 Token-Ring PCI Management Adapter | any |
IBM 16/4 Token-Ring PCI Management Adapter | any |
IBM 16/4 Token-Ring PCI Adapter 2 | PX15C0CT or later |
IBM 16/4 Token-Ring PCI Adapter 2 with Wake on LAN | AL15DAAA or later |
IBM High-Speed 100/16/4 Token-Ring PCI Adapter | HSS2DAB4 or later |
IBM PCI Wake on LAN Token-Ring Adapter | PX14D0CS or later |
For more information about Quick Failover, see Quick Failover.
The Redundant NIC function provides a high-availability solution for your Windows NT Server 3.51 and 4.0 or NetWare 4.11, 4.2 and 5.0 server. This function maintains network connectivity in the event of an adapter- or lobe-related failure. You can assign a backup adapter to take control of the network connection if the active adapter fails.
The Redundant NIC function will initiate a failover when a cable fault or a hard error occurs on the adapter. A failover causes the driver to switch traffic from the active adapter to the backup adapter. The active and backup roles are traded between the adapters of the redundant pair.
In many cases, the failover to the backup adapter will occur seamlessly. Due to the failover latency involved in opening the backup adapter onto the ring, some protocols might require that sessions be reestablished. In either case, network connectivity is maintained and server downtime is avoided.
The Redundant NIC function provides a high-availability solution for your token-ring connected servers. The goal of Redundant NIC is to maintain network connectivity in the event of an adapter- or lobe-related failure.
During driver configuration, users can define a Redundant NIC pair. The pair consists of an active adapter and a backup adapter. The backup adapter will take over in the event of a failure on the active adapter. These failovers can occur continually as long as the backup adapter is operational. Redundant NIC is offered on Windows NT and NetWare server systems. The LAN Adapter Management Agent can be used to complement the Redundant NIC function on Windows NT.
The Agent will send a DMI indication and SNMP trap upon detecting the completion of a Redundant NIC failover. The Agent also allows a failover to be initiated via DMI or SNMP. The Agent also provides the addresses of the active and backup adapters, a running count of failovers and the status of the backup adapter. The Nways Management Applications format the contents of the failover SNMP trap into a clear message.
The combined Redundant NIC and Agent functions should be used on mission-critical servers, and the Nways Management Applications should be used to monitor those servers. Redundant NIC provides the continual network connectivity necessary for the clients using the Windows NT Server. The Agent sends the failover SNMP trap to the Nways Management Application, or any other SNMP-based network management application. Once notified of the server failover, the network administrator can correct the error. For example, the error might be an accidentally disconnected cable. Once the cable has been reconnected, the network administrator can then force a failover from the management application and restore the server's original adapter configuration.
Quick Failover (QFO) is an extension to original Redundant NIC. QFO reduces the failover time from around 30 seconds to less than 10 seconds, and it allows the primary and secondary adapter pair to be in any PCI slot in the system. QFO is supported on Windows NT 4.0 SP 5, NetWare (4.11, 4.2) with IWSP6A and NetWare 5.0 with NW5SP2A.QFO for NetWare also has an enhanced user interface from the original RNIC for NetWare release. You can find additional information on NetWare Quick Failover device driver parameters in the "Novell NetWare Server driver parameters" section of the User's Guide for your adapter.
In addition to having an adapter that supports this feature, you must also have the proper device driver and microcode. See Supported environments for a list of the device drivers and microcode. On Windows NT, if your adapter or microcode level is different from those listed, the device driver automatically defaults to the regular Redundant NIC functions.
Follow these instructions when setting up a Redundant NIC pair.
The LAN Adapter Management Agent Version 1.40 or later allows you to manage the Redundant NIC operation. In the event of a failover, the Agent sends an SNMP trap to notify that a failover has occurred. The user can also initiate a failover through the Agent. For more information about the Agent, see LAN Adapter Management Agent. For an example of using the Agent and Redundant NIC, see Example scenarios.
The Redundant NIC function is provided in two pieces: IBMRNIC.NLM and IBMTRPO.LAN. When a failover from the active to the backup adapter occurs, the only protocols that can be switched are IP and IPX. Any other protocol information that is bound to the active adapter will be lost.
Note: | The only protocol information that is retained when a failover occurs is what is bound to the active adapter when the problem occurs. No conflicting protocols should be bound to the backup adapter. The only exception to this is when ROUTE.NLM is used. In that case, ROUTE.NLM should be bound to the active and backup adapters. |
Failovers can occur from the active to the backup adapter, and also from the backup to the active until a good connection is made. If the backup adapter is not an IBM token-ring PCI adapter, only one automatic failover to the backup is supported. The Redundant NIC NLM can monitor four pairs at one time.
IBMRNIC.NLM Version 2.53 or later has some new features. Quick Failover, which allows failovers to occur much more quickly than normal failovers, is a significant new feature. To take advantage of Quick Failover you must have IBMTRPO.LAN Version 2.46 or later. Additionally, your adapter must be using a microcode version specified in Supported environments or later. Use the flash update tool available from your manufacturer if an adapter microcode update is necessary. Failback is an additional new feature. Failback causes failovers to occur automatically when the secondary adapter is active and when it can be determined that the primary adapter could be active instead. This feature requires you to use Quick Failover on the primary adapter. Failback is enabled by default, but can be disabled when a pair is created. In Versions 2.53 or later of IBMRNIC.NLM, a new user interface allows you to create pairs more easily. This user interface replaces many of the command line functions used in previous versions of the Redundant NIC NLM. The user interface provides functions that allow the user to get the current status of all pairs, cause manual failovers to occur, change the switching status, create, remove, save and load pairs
Versions of IBMTRPO.LAN prior to Version 2.14 will not work with the Redundant NIC capability. To use Quick Failover you need IBMTRPO.LAN Version 2.46 or later along with an adapter using a microcode version specified in Supported environments or later. Each adapter must be plugged into the same ring on the network for the failover to be completely transparent to the clients communicating with the server.
The driver communicates adapter failures or cable disconnects to the IBMRNIC. NLM via the NESL/NEB interface. If ODINEB.NLM loads after the LAN driver, these messages are never sent to the IBMRNIC NLM by the NESL/NEB subsystem. If the IBMRNIC.NLM does not failover after a cable disconnect or failure, verify that ODINEB.NLM is loading before the LAN driver. Make sure that you do not unload ODINEB.NLM while IBMRNIC.NLM is loaded. ODINEB.NLM lets you unload it at any time even if other NLMs depend on it to be loaded.
If you use INETCFG.NLM to configure your system, follow the steps in Installation using INETCFG.NLM instead of the following INSTALL.NLM section.
Support packs are available at http://support.novell.com.
See Setting up a Redundant NIC pair for more information on IBMRNIC command line parameters.
Note: | If the secondary adapter is not an IBM token-ring PCI adapter, the -backup parameter must be used on the pair line. Also, because the secondary adapter probably will not support the standby keyword, the primary adapter must be loaded with the standby keyword. |
Note: | Double-check your AUTOEXEC.NCF every time that you use the INSTALL.NLM program. It is possible that the INSTALL.NLM will move or remove ODINEB.NLM. Make sure that it loads before the network driver (IBMTRPO.LAN) and that IBMRNIC loads after the network driver. |
Since the User-specified Protocol that you created does not exist, no protocols will actually be bound to the secondary adapter. You might notice error messages that point this out when the server is starting up. These messages are for information only; no action is required.
See Setting up a Redundant NIC pair.
Note: | If the secondary adapter is not an IBM token-ring PCI adapter, the -backup parameter must be used on the IBMRNIC pair line. The primary adapter must also be loaded with the standby keyword. |
Note: | Double-check your AUTOEXEC.NCF every time you use the INETCFG.NLM program. It is possible that the INETCFG.NLM will move or remove ODINEB.NLM. Make sure that it loads before the network driver (IBMTRPO.LAN) and that IBMRNIC loads after the network driver. |
Follow these instructions to prepare IBMRNIC.NLM to monitor your adapter pair.
The Redundant NIC NLM requires that several options be specified in order to create a pair. You can specify the options to IBMRNIC.NLM when you load the nlm or on the command line after IBMRNIC.NLM is loaded. To automate the commands on reboot, add them to your AUTOEXEC.NCF.
To complete the setup, you need the following information:
Note: | If the IBM token-ring PCI adapter driver (IBMTRPO.LAN) is loaded with the option to enable Quick Failover, the adapter will not become active until a Redundant NIC pair is made with that adapter. You will not be able to use that adapter until a pair is made. |
To set up a pair when you load the NLM, use the following format:
load ibmrnic pair <pairname> -p<slot#> -s<slot#> | -x<base address> [-r<ip_address>] [-backup]
If IBMRNIC is already loaded you can set up a pair by using the IBMRNIC keyword on the system console. Its format is:
ibmrnic pair <pairname> -p<slot#> -s|x<slot#> -r<ip_address> [-backup]
A description of each parameter follows:
As stated previously, the ibmrnic command can be used on the system console after IBMRNIC.NLM is loaded. This command can be used to create a pair and to get help on creating pairs. A user interface is started on a panel separate from the System Console that is used to modify your pairs. In versions of the Redundant NIC NLM prior to Version 2.50 all redundant NIC operations were performed on the command line. Now, only the pair and help commands are supported. The new user interface provides all of the other functions along with some extra functions. The user interface allows you to create, remove, save, and load pairs. You can also perform manual failovers and change the switching mode. The most recent status of all configured pairs is always shown on the screen.
ibmrnic help
Enter ibmrnic help to show the valid options for the ibmrnic command.
ibmrnic pair
This command is described in Setting up a Redundant NIC pair.
Create
Press the Insert key to display a form that helps you create a pair. Fill in all of the fields of the form and select create. The fields are the pair name, the primary slot, the secondary slot/port, the IP router and failback enable/disable.
Delete
Press the Delete key to remove a pair. A list box with all configured pair names appears. Select the name of the pair you would like to remove. If more than one pair exists, there is an entry that you can select to remove all pairs.
Failover
Press the F8 key to cause a failover to occur on a pair that you select. A list box with all configured pairs appears. When you select a pair from the list, a failover occurs from the active to the backup on that pair.
Mode
Press the F9 key to change the switching mode of an adapter. Select the pair name for which you want to change the mode. Then select the new mode for that pair.
Normally the Redundant NIC pair will automatically failover from the active to the backup if a cable fault or adapter failure is detected. Use this command to change the mode of the pair so that an automatic failover will not occur. To prevent automatic failovers from occurring, set the pair to manual mode. In manual mode, the ibmrnic switch command is the only way to failover from the active to the backup adapter. Disabled mode will not allow failovers. You can use disabled mode when performing maintenance on the backup adapter.
Save
Press the F4 key to save the configuration of all of the current pairs to a file. You must save the configuration to one of the files that is specified in the list box that appears.
Load
Press the F5 key to load the configuration from a previously saved file and then select the file you want to use to restore your configuration.
The configuration can also be restored from one of the saved files when IBMRNIC.NLM initially loads. To do this, specify the number of the file your configuration was saved to. For example, if the file name is IBMRNIC0.DAT, then to load IBMRNIC with the configuration stored in IBMRNIC0.DAT you would enter:
load ibmrnic 0
The files operated on by the Save and Load options are located in the sys:/system directory of the server.
The status of all pairs is shown in the main portal of the IBMRNIC window. If a pair is configured the following information will be displayed: the pair name and LAA (locally administered address), the slots that the primary and secondary adapters are using, the switching mode of the pair (manual, automatic, or disabled), the current state of the primary adapter, the current state of the secondary adapter, the number of failovers that have occurred, and the time the last failover occurred. Because all of this information can not be shown at one time, you must press the F1 key to toggle between the pair information and the adapter information.
Note: | The terms primary and secondary do not refer to which adapter is currently active. The primary adapter is initially the active adapter and was configured by using the -p<<slot#> option on the command line. The secondary adapter is initially the backup adapter and was referred to by -s<<slot#> or -x<<hex port#> on the command line. |
There are several possible states that apply to an adapter. The possible states are:
The Redundant NIC NLM can be used in a server that supports PCI Hot-Plug, but some manual intervention is required to maintain its proper operation. If an adapter is removed that is part of an IBMRNIC pair, then failovers will no longer occur. If the active adapter in a pair is removed, then a failover will occur. After a hot-plug operation has been completed, the adapter driver must be loaded manually. Do not let HWDETECT.NLM attempt to automatically load the driver for the adapter. HWDETECT.NLM will not load the driver with the correct parameters needed to get the Redundant NIC pair operational again.
To perform a failover, perform the following procedure:
Note: | If the secondary adapter is not an IBM token-ring PCI adapter ,and you are trying to reload its driver, you might have problems if the driver does not have an equivalent of the standby parameter. |
set Time Zone = EST5EDT set Daylight Savings Time Offset = 1:00:00 set Start Of Daylight Savings Time = (APRIL SUNDAY FIRST 2:00:00 AM) set End Of Daylight Savings Time = (OCTOBER SUNDAY LAST 2:00:00 AM) set Default Time Server Type = SINGLE # Note: The Time zone information mentioned above # should always precede the SERVER name. set Bindery Context = O=workgroup file server name NWSRV1 ipx internal net 60990060 # The network environment for this server consists # of a Token-Ring LAN with only one Frame Type load tcpip load odineb # Primary adapter LOAD IBMTRPO SLOT=3 RNICOPEN=400010203182 FRAME=TOKEN-RING NAME=IBMTRPO_1_TOK BIND IPX IBMTRPO_1_TOK NET=ABCD1 # Secondary adapter loaded with the same frame type as the Primary LOAD IBMTRPO SLOT=2 RNICOPEN=400010203182 FRAME=TOKEN-RING NAME=IBMTRPO_2_TOK # Create the Redundant NIC pair with Primary slot=3, and Secondary Slot=2 load ibmrnic pair mypair -p3 -s2 mount all
set Time Zone = EST5EDT set Daylight Savings Time Offset = 1:00:00 set Start Of Daylight Savings Time = (APRIL SUNDAY FIRST 2:00:00 AM) set End Of Daylight Savings Time = (OCTOBER SUNDAY LAST 2:00:00 AM) set Default Time Server Type = SINGLE # Note: The Time zone information mentioned above # should always precede the SERVER name. set Bindery Context = O=workgroup file server name NWSRV1 ipx internal net 60990060 # The network environment for this server includes both Token-Ring frame # types, utilizes Source Routing, has an IP network with a default IP gateway, # and utilizes Route Switching via the IBM 8210 LOAD IPXRTR routing=NLSP load tcpip load odineb # Primary Adapter LOAD IBMTRPO SLOT=3 NODE=400010203182 RT=C FRAME=TOKEN-RING NAME=IBMTRPO_1_TOK BIND IPX IBMTRPO_1_TOK NET=ABCD1 LOAD IBMTRPO SLOT=3 NODE=400010203182 RT=C FRAME=TOKEN-RING_SNAP NAME=IBMTRPO_1_TSP BIND IPX IBMTRPO_1_TSP NET=FF1 BIND IP IBMTRPO_1_TSP ADDR=10.20.31.82 MASK=ff.ff.ff.0 GATE=10.20.31.254 # Secondary Adapter with the same frame types as Primary loaded, but no # bindings LOAD IBMTRPO SLOT=2 NODE=400010203182 STANDBY RT=C FRAME=TOKEN-RING NAME=IBMTRPO_2_TOK LOAD IBMTRPO SLOT=2 NODE=400010203182 STANDBY RT=C FRAME=TOKEN-RING_SNAP NAME=IBMTRPO_2_TSP # Create the Redundant NIC pair with the Primary slot=3, the Secondary # slot=2, and the Default IP gateway=10.20.31.254 load ibmrnic pair mypair -p3 -s2 -r10.20.31.254 # If Source Routing is needed, then route.nlm must be loaded for # all the logical boards of both the primary and secondary adapter load route name=ibmtrpo_1_tok rsp=ar time=10 load route name=ibmtrpo_1_tsp rsp=ar time=10 load route name=ibmtrpo_2_tok rsp=ar time=10 load route name=ibmtrpo_2_tsp rsp=ar time=10 mount all
set Time Zone = EST5EDT set Daylight Savings Time Offset = 1:00:00 set Start Of Daylight Savings Time = (APRIL SUNDAY FIRST 2:00:00 AM) set End Of Daylight Savings Time = (OCTOBER SUNDAY LAST 2:00:00 AM) set Default Time Server Type = SINGLE # Note: The Time zone information mentioned above # should always precede the SERVER name. set Bindery Context = O=workgroup file server name NWSRV2 ipx internal net 35083DE8 ; Network driver LOADs and BINDs are initiated via ; INITSYS.NCF. The actual LOAD and BIND commands ; are contained in INITSYS.NCF and NETINFO.CFG. ; These files are in SYS:ETC. load odineb sys:etc\initsys.ncf load ibmrnic pair mypair -p7 -s6 mount all
# The network environment for this server consists # of a Token-Ring LAN with only one Frame Type LOAD SNMP LOAD IBMTRPO NAME=TOK1_TOK FRAME=TOKEN-RING SLOT=7 NODE=400010203181 RXBUFFERS=32 TXBUFFERS=16 DATARATE=AUTO FULLDUPLEX=YES RTSWENABLE=NO LOAD IBMTRPO NAME=TOK2_TOK FRAME=TOKEN-RING SLOT=6 NODE=400010203181 RXBUFFERS=32 TXBUFFERS=16 DATARATE=AUTO FULLDUPLEX=YES STANDBY RTSWENABLE=NO BIND IPX TOK1_TOK net=abcd1 seq=1 LOAD DUMMY BIND DUMMY TOK2_TOK
# The network environment for this server includes both Token-Ring frame # types, utilizes Source Routing, has an IP network with a default IP gateway, # and utilizes Route Switching via the IBM 8210 LOAD SNMP LOAD IBMTRPO NAME=TOK1_TOK FRAME=TOKEN-RING SLOT=7 NODE=400010203181 RXBUFFERS=32 TXBUFFERS=16 DATARATE=AUTO FULLDUPLEX=YES RT=C RTTS=1024 LOAD IBMTRPO NAME=TOK1_TSP FRAME=TOKEN-RING_SNAP SLOT=7 NODE=400010203181 RXBUFFERS=32 TXBUFFERS=16 DATARATE=AUTO FULLDUPLEX=YES RT=C RTTS=1024 LOAD IBMTRPO NAME=TOK2_TOK FRAME=TOKEN-RING SLOT=6 NODE=400010203181 RXBUFFERS=32 TXBUFFERS=16 DATARATE=AUTO FULLDUPLEX=YES STANDBY RT=C RTTS=1024 LOAD IBMTRPO NAME=TOK2_TSP FRAME=TOKEN-RING_SNAP SLOT=6 NODE=400010203181 RXBUFFERS=32 TXBUFFERS=16 DATARATE=AUTO FULLDUPLEX=YES STANDBY RT=C RTTS=1024 LOAD IPXRTR ROUTING=NLSP BIND IPX TOK1_TOK net=abcd1 seq=1 BIND IPX TOK1_TSP net=ff1 seq=2 LOAD ROUTE NAME=TOK1_TOK RSP=AR TIME=10 LOAD ROUTE NAME=TOK1_TSP RSP=AR TIME=10 LOAD ROUTE NAME=TOK2_TOK RSP=AR TIME=10 LOAD ROUTE NAME=TOK2_TSP RSP=AR TIME=10 LOAD Tcpip RIP=Yes Forward=No BIND IP TOK1_TSP ARP=Yes Mask=ff.ff.ff.0 Address=10.20.31.81 LOAD DUMMY BIND DUMMY TOK2_TOK BIND DUMMY TOK2_TSP
set Time Zone = EST5EDT set Daylight Savings Time Offset = 1:00:00 set Start Of Daylight Savings Time = (APRIL SUNDAY FIRST 2:00:00 AM) set End Of Daylight Savings Time = (OCTOBER SUNDAY LAST 2:00:00 AM) set Default Time Server Type = SINGLE # Note: The Time zone information mentioned above # should always precede the SERVER name. set Bindery Context = O=workgroup file server name NWSRV1 ipx internal net 60990060 # The network environment for this server consists # of a Token-Ring LAN with only one Frame Type load tcpip load odineb # Primary adapter 1 LOAD IBMTRPO SLOT=4 NODE=400000000004 DATARATE=M16 STANDBY FRAME=TOKEN-RING NAME=IBMTRPO_4_TOK BIND IPX IBMTRPO_4_TOK NET=1234 #Secondary adapter 1 (notice this adapter is not an IBM PCI Token-Ring adapter) LOAD IBMMPCO SLOT=5 NODE=400000000004 DATARATE=16 ENABLEFDX FRAME=TOKEN-RING NAME=IBMMPCO_5_TOK # Primary adapter 2 LOAD IBMTRPO SLOT=3 NODE=400010203182 FRAME=TOKEN-RING NAME=IBMTRPO_1_TOK BIND IPX IBMTRPO_1_TOK NET=ABCD1 # Secondary adapter loaded with the same frame type as the Primary 2 LOAD IBMTRPO SLOT=2 NODE=400010203182 STANDBY FRAME=TOKEN-RING NAME=IBMTRPO_2_TOK # Create the Redundant NIC pair with Primary slot=4, and Secondary # Slot=5 (this pair uses the -backup parameter because the Secondary # adapter is not an IBM PCI Token-Ring adapter) load ibmrnic pair bkpair -p4 -s5 -backup # Create the Redundant NIC pair with Primary slot=3, and Secondary Slot=2 ibmrnic pair mypair -p3 -s2 mount all
RNIC-100: | FAILED TO ALLOCATE MEMORY FOR LAN BOARDS
Explanation: Your server is not able to allocate memory for IBMRNIC.NLM User Action: Try unloading NLMs that are not needed or add more memory to the server. |
RNIC-101: | FAILED TO REGISTER FOR ONE OR MORE NESL EVENTS.
Explanation: The Redundant NIC NLM was unable to register for some NESL/NEB events. This could prevent the Redundant NIC pairs from functioning correctly. User Action: Update MSM.NLM to the latest available level. |
RNIC-102: | PAIRING SUCCEEDED
Explanation: A Redundant NIC pair was created successfully and will be monitored for events from the adapters that make up the pair. User Action: None. |
RNIC-103: | MUST SPECIFY -P AND -S OR -X TO CREATE A REDUNDANT NIC PAIR
Explanation: The Redundant NIC NLM must be told the slot for the primary and secondary adapters when a pair is created. User Action: See Setting up a Redundant NIC pair for information about creating a pair. |
RNIC-104: | MUST SPECIFY A NAME FOR A REDUNDANT NIC PAIR
Explanation: Redundant NIC pairs must be given a name for the pairing to be completed. User Action: Try to create the pair again and specify a pair name. |
RNIC-105: | PAIR NAME IN USE. CHOOSE ANOTHER NAME.
Explanation: You tried to use an existing pair name for another pair. User Action: None. |
RNIC-106: | THE DEFAULT IP ROUTER ADDRESS THAT WAS SPECIFIED IS INVALID.
Explanation: The default IP router address format that you specified was incorrect. User Action: Verify the IP address of your router. |
RNIC-107: | UNABLE TO GET OPTIONS STRUCTURE MEMORY.
Explanation: There was a problem allocating memory. The server could be out of memory or there could be a problem with CLIB.NLM. User Action: Try unloading NLMs that are not needed or add more memory to the server. |
RNIC-108: | NO REDUNDANT NIC PAIRS LOADED
Explanation: There are no configured pairs to show at this time. User Action: None. |
RNIC-109: | ERROR READING PAIR INFORMATION FROM FILE
Explanation: Redundant NIC was unable to load one or more pairs from a saved configuration file. User Action: Try recreating the pairs and resaving the file. |
RNIC-110: | ALL PAIRS WERE REMOVED.
Explanation: All Redundant NIC pairings were successfully removed. User Action: None. |
RNIC-111: | INVALID REDUNDANT NIC PAIR NAME
Explanation: The pair name specified with the ibmrnic switch command does not exist. User Action: Use ibmrnic show to determine the correct name. |
RNIC-112: | MANUAL ADAPTER FAILOVER SUCCEEDED
Explanation: An ibmrnic switch command was issued to a Redundant NIC pair and the failover completed successfully. User Action: None. |
RNIC-113: | INVALID IBMRNIC SWITCH COMMAND
Explanation: The ibmrnic switch command that you specified was not correct. User Action: Enter ibmrnic help to get help with the ibmrnic command. |
RNIC-114: | SWITCH MODE SET TO <MODE>
Explanation: The Redundant NIC switch mode was successfully set to the specified mode. User Action: None. |
RNIC-115: | COULD NOT START THREAD TO HANDLE KEYBOARD REQUESTS
Explanation: A new thread failed to start. User Action: Unload the NLM and reload it. Some memory may need to be freed. |
RNIC-116: | <PAIRNAME> UNPAIRED SUCCESSFULLY
Explanation: The Redundant NIC pair <pairname> was removed successfully. User Action: None. |
RNIC-117: | UNKNOWN OR MALFORMED COMMAND
Explanation: You typed in a command that was not valid. User Action: Type ibmrnic help to get help with the ibmrnic command. |
RNIC-118: | ERROR SAVING PAIR INFORMATION TO THE FILE
Explanation: The configuration for the pairs could not be saved. User Action: Verify that there is space available for new files. |
RNIC-119: | THE SETTINGS WERE SAVED TO THE FILE SUCCESSFULLY
Explanation: The current configuration was correctly saved to a file. User Action: None. |
RNIC-120: | USE THE IBMRNIC UTILITY SCREEN TO PERFORM THIS OPERATION
Explanation: Instead of using the console command line, use the NWSNUT interface. User Action: Try performing the command using the NWSNUT utility. |
RNIC-121: | INVALID FILE NUMBER SPECIFIED
Explanation: The file number specified on the command line is invalid. User Action: Choose a file number from that is valid. |
RNIC-122: | THE FAIL BACK FUNCTION COULD NOT BE STARTED
Explanation: The thread that performs the fail back function did not start. User Action: Unload and then reload IBMRNIC.NLM. |
RNIC-123: | THE GRAPHICAL INTERFACE WAS NOT INITIALIZED
Explanation: There was a problem starting the NWSNUT utility for Redundant NIC. User Action: Try unloading and then reloading IBMRNIC.NLM. |
RNIC-124: | CREATING DEFAULT INI FILE
Explanation: A default INI file is being created because the current INI file cannot be found. User Action: None. |
RNIC-125: | INVALID FILE FORMAT, USING BUILT IN DEFAULTS
Explanation: The INI file is invalid and will not be used. User Action: Correct the problem introduced to the INI file or delete it so IBMRNIC can recreate the default file. |
RNIC-126: | INVALID VALUE IN INI FILE
Explanation: An entry in the INI file was found to be incorrect. User Action: Correct any problems in the INI file. |
RNIC-127: | COULD NOT START THREAD TO HANDLE COMMAND LINE
Explanation: The thread that processes the IBMRNIC command line did not get started. User Action: Try unloading and reloading IBMRNIC.NLM. |
RNIC-128: | PROBLEM ALLOCATING RESOURCE TAGS
Explanation: There was not enough memory to allocate resource tags for IBMRNIC.NLM. User Action: Unload and reload IBMRNIC.NLM. |
RNIC-200: | UNABLE TO GET PARAMETER STRUCTURE MEMORY
Explanation: Your server is not able to allocate memory for IBMRNIC.NLM. User Action: Try unloading NLMs that are not needed or add more memory to the server. |
RNIC-201: | SETUP FAILED: INVALID COMMAND LINE FORMAT
Explanation: You typed an ibmrnic pair parameter that was not valid. User Action: Enter ibmrnic help to get help with the ibmrnic command. |
RNIC-202: | SETUP FAILED: UNABLE TO GET MEMORY FOR RNIC PROFILE
Explanation: Your server is not able to allocate memory for IBMRNIC.NLM. User Action: Try unloading NLMs that are not needed or add more memory to the server. |
RNIC-203: | SETUP FAILED: PROBLEM INITIALIZING THE ADAPTER PAIR
Explanation: The initialization routine for the pair failed. User Action: Try creating the pair again. |
RNIC-204: | SETUP FAILED: PARAMETERS STRUCTURE IS MISSING
Explanation: There was a problem accessing the parameters structure. User Action: Try setting up the pair again. |
RNIC-205: | SETUP FAILED: FAILED TO FIND ANY LOADED IBM TOKEN-RING
BOARDS.
Explanation: The Redundant NIC NLM was not able to find any IBM token-ring boards loaded at this time. User Action: Load token-ring boards for the primary and secondary adapters. |
RNIC-206: | SETUP FAILED: PRIMARY ADAPTER NOT FOUND
Explanation: There is no adapter in the slot that you specified as primary. User Action: Specify the correct slot. |
RNIC-207: | SETUP FAILED: COULD NOT ALLOCATE SPACE TO READ THE MSM CONFIG TABLE
Explanation: Problem allocating memory. It is possible that the machine is low on RAM. User Action: Try unloading NLMs that are not needed or add more memory to the server. |
RNIC-208: | SETUP FAILED: PROBLEM READING THE MSM CONFIG TABLE
Explanation: The Config table for the adapter could not be read. User Action: Make sure that you are using the correct LAN driver. |
RNIC-209: | SETUP FAILED: INCORRECT LAN DRIVER VERSION
Explanation: Your LAN driver is too old. User Action: Use the one that came with the IBMRNIC.NLM diskette or a newer version if one is available. |
RNIC-210: | SETUP FAILED: SECONDARY ADAPTER NOT FOUND
Explanation: There is no adapter in the slot that you specified as secondary. User Action: Specify the correct slot. |
RNIC-211: | SETUP FAILED: PRIMARY AND SECONDARY LOGICAL BOARDS DO NOT MATCH
Explanation: The logical boards on the primary adapter do not match the logical boards on the secondary adapter. User Action: Check the frame types for the primary and secondary adapters. They should match. |
RNIC-212: | SETUP FAILED: PRIMARY AND SECONDARY MAC ADDRESSES DO NOT MATCH
Explanation: The same Locally Administered Address must be assigned to each adapter using the node address=<LAA> command line keyword. User Action: Set the Locally Administered Address on the primary and secondary adapters to the same address. |
RNIC-213: | SETUP FAILED: COULD NOT FIND MLID CONFIG TABLE TO PERFORM ADAPTER
STATUS CHECK
Explanation: There is a problem reading the adapter Config table. User Action: Try setting up the pair again. |
RNIC-214: | SETUP FAILED: THE PRIMARY ADAPTER MUST NOT BE SHUT DOWN
Explanation: The primary adapter must be open in order for Redundant NIC to initialize correctly. User Action: Specify a primary adapter that is not shut down. |
RNIC-215: | SETUP FAILED: THE SECONDARY ADAPTER MUST NOT BE OPEN
Explanation: The secondary adapter must be closed when Redundant NIC is being initialized. User Action: Specify an adapter that was loaded with the standby keyword. |
RNIC-216: | SETUP FAILED: THE PRIMARY ADAPTER COULD NOT ACCEPT THE LAA
Explanation: There was a problem setting up the adapter with the Quick Failover feature. User Action: Make sure the correct level of microcode is on the adapter. |
RNIC-217: | SETUP FAILED: COULD NOT SHUT DOWN THE SECONDARY ADAPTER
Explanation: The secondary adapter did not respond to a request to shut down. User Action: Try setting up the pair again. |
RNIC-218: | SETUP FAILED: THE PRIMARY ADAPTER SPECIFIED IS PART OF ANOTHER PAIR
Explanation: The primary adapter you specified is part of another Redundant NIC pair. User Action: Specify a primary adapter that is not part of a Redundant NIC pair. |
RNIC-219: | SETUP FAILED: THE SECONDARY ADAPTER SPECIFIED IS PART OF ANOTHER
PAIR
Explanation: The secondary adapter you specified is part of another Redundant NIC pair. User Action: Specify a secondary adapter that is not part of a Redundant NIC pair. |
RNIC-220: | SETUP FAILED: FAILED TO RESET THE PRIMARY ADAPTER
Explanation: The primary adapter could not be reset. User Action: Attempt to create the pair again. |
RNIC-221: | SETUP FAILED: THE PRIMARY ADAPTER DOES NOT SUPPORT QUICK FAILOVER
Explanation: The primary adapter must have newer microcode to support Quick Failover. User Action: Update the microcode on the adapter or do not load the adapters driver with the RNICOPEN keyword. |
RNIC-222: | SETUP FAILED: THE SECONDARY ADAPTER DOES NOT SUPPORT QUICK FAILOVER
Explanation: The secondary adapter must have newer microcode to support Quick Failover. User Action: Update the microcode on the adapter or do not load the adapters driver with the RNICOPEN keyword. |
RNIC-223: | SETUP FAILED: THE PRIMARY AND SECONDARY ADAPTERS MUST NOT BE THE
SAME
Explanation: The primary and secondary adapters specified were the same adapter. User Action: Attempt to create the pair again with two adapters. |
RNIC-300: | UNPAIR FAILED: INVALID IBMRNIC PAIR NAME
Explanation: The pair that you tried to remove does not exist. User Action: Enter ibmrnic show to find the correct pair name of the adapters that you would like to remove. |
RNIC-301: | UNPAIR FAILED: COULD NOT REMOVE LINK FROM LIST OF PAIRS
Explanation: There was a problem unpairing the adapters. User Action: Try to remove the pair again. |
RNIC-400: | MANUAL ADAPTER FAILOVER UNSUCCESSFUL: THE SWITCHING MODE IS
DISABLED.
Explanation: When the switching mode is disabled you cannot initiate a manual failover. User Action: Set the switching mode to manual or auto. |
RNIC-401: | MANUAL ADAPTER FAILOVER UNSUCCESSFUL: THE BACKUP ADAPTER IS NOT
ABLE
TO BECOME ACTIVE AT THIS TIME.
Explanation: An attempt was made to failover to the backup adapter. The state of the backup adapter is preventing it from becoming an active adapter. User Action: Make sure that the backup adapter is not open. |
RNIC-402: | MANUAL ADAPTER FAILOVER UNSUCCESSFUL: SHUTDOWN OF ACTIVE ADAPTER
FAILED
Explanation: The active adapter could not be shut down. User Action: Try issuing a manual failover from the command line. |
RNIC-403: | MANUAL ADAPTER FAILOVER UNSUCCESSFUL: FAILED TO ACTIVATE BACKUP
ADAPTER.
Explanation: The backup adapter could not be reset. User Action: Try issuing a manual failover from the command line. |
This chapter describes the Load Balancing and Failover (LBFO) feature.
Load Balancing and Failover (LBFO) is currently supported on the following adapters:
The following operating environments are supported:
Note: | LBFO is independent of Redundant NIC which is described in Redundant NIC |
The Load Balancing Failover (LBFO) function provides a high-availability solution for your Windows 2000 server. This function improves network traffic flow by load-balancing the output of two or more PCI adapters as well as automatically rerouting network traffic around a failed adapter.
LBFO allows you to assign your PCI adapters to logical groupings or "bundles". LBFO balances the output load of the bundle across all the adapters assigned to that bundle.
In the event of an adapter failure (cable fault or a hard error), LBFO reroutes the bundle's traffic to the remaining functional adapters within that bundle.
In many cases, the failover to the other adapters in the bundle will occur seamlessly. Due to the failover latency involved in some protocols, some sessions might need to be reestablished. In either case, network connectivity is maintained and server downtime is avoided.
The LBFO function provides a high-availability, high-throughput solution for your token-ring connected servers. The goal of LBFO is to maintain network connectivity in the event of an adapter failure as well as maximizing the output bandwidth across a group of adapters.
Follow these instructions to install LBFO support.
Note: | You might need to refresh this window if you recently added an adapter. |
If you are removing an adapter from a LBFO bundle, follow these instructions:
If you are adding a newly added adapter to a bundle, follow these instructions:
Note: | You might need to refresh this window if you recently added an adapter. |
If you moving a currently defined adapter from one LBFO bundle to another LBFO bundle, see Changing an adapter's bundle ID.
If you moving a currently defined adapter from one LBFO bundle to another LBFO bundle, follow these instructions:
This chapter describes the Tivoli(R) Management Agent (TMA).
The TMA executes independent of the LAN adapter. As long as the adapter has a device driver for a supported operating system, the TMA will be able to try to connect to a server.
The TMA packages are provided to support the following operating systems:
The Tivoli Management Agent gives you the framework necessary to perform management operations such as software distribution, inventory, user administration and distributed monitoring. Instead of software applications sitting on top of the desktop, the Tivoli Management Agent automatically determines what is needed to perform a given management operation. If that capability already resides on the computer, it immediately proceeds with the operation. If not, the Agent downloads the appropriate software from the server to the desktop with no operator intervention.
In addition, the Agent downloads newer versions as updates are loaded on the server.You can gain significant productivity advances with these management features because Tivoli Management Software is installed only once on the server with updates performed automatically thereafter.
For more information about Tivoli Systems and Tivoli-Ready(TM) initiatives, visit the Tivoli Web site at http://www.tivoli.com
To begin the installation, you must first get the installation package. See Downloads. After you have downloaded the package, execute the package to expand the files.
Note: | NetWare installations must be done from a NetWare client. |
Use the procedures in the following sections to configure the TMA.
nw3xins x
nw4_5ins x
This machine has the Tivoli Management Agent installed in an inactive state.
If you want this machine to become part of your Tivoli Enterprise you will need to activate or wake up the agent. The Tivoli Enterprise includes a computer with a gateway that the TMA will need to log in to. As user or system administrator, you can ensure that the TMA is activated correctly and joins the Tivoli Enterprise by following the instructions in this section. This process only needs to be performed once. After this activation, the TMA is running on the machine and is configured to start and log in to the TMR every time the machine starts.
Your installation includes a logon script that can be used to automate the one-time setup process described in this section. See c:\tivoli\lcf\generic\logontma.bat
The steps in this section can be performed in any order. The first two steps are not necessary to start the TMA, but are necessary for running of Tivoli methods once the endpoint joins the TMR.
Activate the Tivoli Authentication Process (TAP): run c:\tivoli\lcf\bin\w32-ix86\mrt\wlcftap.exe -a Reboot your computer.
Add the Tivoli reserved user (nobody): run c:\tivoli\lcf\bin\w32-ix86\mrt\ntconfig.exe -e
Start the Tivoli Management Agent: c:\tivoli\lcf\bin\w32-ix86\mrt\lcfd.exe with the following options:
Note: | Options are case-sensitive. |
Option | Function |
---|---|
-C working directory | (Uppercase C) This causes the TMA to change the working directory to working directory when starting. The value should always be C:\Tivoli\lcf\dat\1 |
-i | Installs the TMA as an NT service. This also configures the TMA for autostart when the computer boots. |
If the TMA is started without the -g option the endpoint will immediately broadcast a message in search of a Tivoli Management Gateway on its subnet. This is not recommended for most customers. Therefore, please use the following options to specify a Tivoli Management Gateway. | |
-g gateway+port | Contacts the specified Tivoli Management Gateway for initial login. gateway_address is the hostname or IP address of the Tivoli Management Gateway that the endpoint will log into. port is the listening port of the gateway. |
-p port | Contacts the gateway on the specified port. port is the listening port of the gateway. |
-P port | (Uppercase P) Specifies a local port for use by the TMA. port is the listening port of the TMA. |
To view a Usage statement and see all the options that can be used in starting the endpoint, run C:\Tivoli\lcf\bin\w32-ix86\mrt\lcfd.exe -s -D?
Type C:\Tivoli\lcf\bin\w32-ix86\mrt\lcfep.exe -x -i to install the taskbar icon. To remove, use the -s option.
This computer has the Tivoli Management Agent installed in an inactive state.
If you want this computer to become part of your Tivoli Enterprise, you will need to activate or wake up the agent. The Tivoli Enterprise includes a computer with a gateway where this TMA will log in. As user or system administrator, you can ensure that the TMA is activated correctly and joins the Tivoli Enterprise by following the instructions in this section. This process only needs to be performed once. After this activation, the TMA is running on the computer and is configured to start and log in to the TMR every time the computer starts.
Your installation includes a logon script that can be used to automate the one-time setup process described in this section. See c:\Tivoli\lcf\generic\logontma.bat
To activate the TMA, start LCFD.EXE from the command line using options to identify the correct gateway (Tivoli Management Gateway). For example, some companies have one gateway that the whole company logs into, others have many different choices. The Tivoli Administrator will provide this information.
Start the Tivoli Management Agent
C:\Tivoli\lcf\bin\win95\mrt\lcfd.exe with the following options:
Note: | Options are case-sensitive. |
Option | Function |
---|---|
-C working directory | (Uppercase C) This causes the TMA to change the working directory to working directory when starting. The value should always be C:\Tivoli\lcf\dat\1 |
If the TMA is started without the -g option the endpoint will immediately broadcast a message in search of a Tivoli Management Gateway on its subnet. This is not recommended for most customers. Therefore, please use the following options to specify a Tivoli Management Gateway. | |
-g gateway+port | Contacts the specified Tivoli Management Gateway for initial login. gateway_address is the hostname or IP address of the Tivoli Management Gateway that the endpoint will log into. port is the listening port of the gateway. |
-p port | Contacts the gateway on the specified port. port is the listening port of the gateway. |
-P port | (Uppercase P) Specifies a local port for use by the TMA. port is the listening port of the TMA. |
To view a Usage statement and see all the options that can be used in starting the endpoint, run C:\Tivoli\lcf\bn\win95\mrt\lcfd.exe -s -D?
To activate the taskbar icon you need to start lcfep.exe -x -i
This computer has the Tivoli Management Agent installed in an inactive state.
If you want this computer to become part of your Tivoli Enterprise, you will need to activate or wake up the agent. The Tivoli Enterprise includes a computer with a gateway where this TMA will log in. As user or system administrator, you can ensure that the TMA is activated correctly and joins the Tivoli Enterprise by following the instructions in this section. This process only needs to be performed once. After this activation, the TMA is running on the computer and is configured to start and log in to the TMR every time the computer starts.
Note: | Even though the steps in this section are in a certain order, the first step can be performed at any time. The next step must be performed before the third. |
Add the line sys\system\lcf.ncf to your AUTOEXEC.NCF file.
Add command line parameters to the line that loads LCFD.NLM in sys:\system\lcf.ncf and sys:\system\tivoli\lcf\1\lcf.ncf. They should include options to identify the correct gateway (Tivoli Management Gateway). For example, some companies have one gateway that the whole company logs into. Others have many different choices. The Tivoli Administrator will provide this information.
Note: | Options are case-sensitive. |
Option | Function |
---|---|
-C working directory | (Uppercase C) This causes the TMA to change the working directory to working directory when starting. The value should always be C:\Tivoli\lcf\dat\1 |
If the TMA is started without the -g option the endpoint will immediately broadcast a message in search of a Tivoli Management Gateway on its subnet. This is not recommended for most customers. Therefore, please use the following options to specify a Tivoli Management Gateway. | |
-g gateway+port | Contacts the specified Tivoli Management Gateway for initial login. gateway_address is the hostname or IP address of the Tivoli Management Gateway that the endpoint will log into. port is the listening port of the gateway. |
-p port | Contacts the gateway on the specified port. port is the listening port of the gateway. |
-P port | (Uppercase P) Specifies a local port for use by the TMA. port is the listening port of the TMA. |
Type lcf This will load LCFUTILS.NLM and LCFD.NLM.
Type unload lcfd then unload lcfutils
To view a usage statement and see all of the options that can be used in starting the endpoint, run load sys:\system\Tivoli\lcf\bin\nw3\mrt\lcfd.exe -s -D?
This computer has the Tivoli Management Agent installed in an inactive state.
If you want this computer to become part of your Tivoli Enterprise, you will need to activate or wake up the agent. The Tivoli Enterprise includes a computer with a gateway where this TMA will log in. As user or system administrator, you can ensure that the TMA is activated correctly and joins the Tivoli Enterprise by following the instructions in this section. This process only needs to be performed once. After this activation, the TMA is running on the computer and is configured to start and log in to the TMR every time the computer starts.
Note: | Even though the steps in this section are in a certain order, the first step can be performed at any time. The next step must be performed before the third. |
Add the line sys\system\lcf.ncf to your autoexec.ncf file.
Add command line parameters to the line that loads LCFD.NLM in sys:\system\lcf.ncf and sys:\system\tivoli\lcf\1\lcf.ncf. They should include options to identify the correct gateway (Tivoli Management Gateway). For example, some companies have one gateway that the whole company logs into. Others have many different choices. The Tivoli Administrator will provide this information.
Note: | Options are case-sensitive. |
Option | Function |
---|---|
-C working directory | (Uppercase C) This causes the TMA to change the working directory to working directory when starting. The value should always be C:\Tivoli\lcf\dat\1 |
If the TMA is started without the -g option the endpoint will immediately broadcast a message in search of a Tivoli Management Gateway on its subnet. This is not recommended for most customers. Therefore, please use the following options to specify a Tivoli Management Gateway. | |
-g gateway+port | Contacts the specified Tivoli Management Gateway for initial login. gateway_address is the hostname or IP address of the Tivoli Management Gateway that the endpoint will log into. port is the listening port of the gateway. |
-p port | Contacts the gateway on the specified port. port is the listening port of the gateway. |
-P port | (Uppercase P) Specifies a local port for use by the TMA. port is the listening port of the TMA. |
Type lcf This will load LCFUTILS.NLM and LCFD.NLM.
Type unload lcfd then unload lcfutils
To view a usage statement and see all of the options that can be used in starting the endpoint, run load sys:\system\Tivoli\lcf\bin\nw4\mrt\lcfd.exe -s -D?
This computer has the Tivoli Management Agent installed in an inactive state.
If you want this computer to become part of your Tivoli Enterprise, you will need to activate or wake up the agent. The Tivoli Enterprise includes a computer with a gateway where this TMA will log in. As user or system administrator, you can ensure that the TMA is activated correctly and joins the Tivoli Enterprise by following the instructions in this section. This process only needs to be performed once. After this activation, the TMA is running on the computer and is configured to start and log in to the TMR every time the computer starts.
Note: | Even though the steps in this section are in a certain order, they can be performed in any order. The first step is not necessary to start the TMA, but it is necessary for running the TMA after a reboot. |
Add an entry to the Startup Folder to run c:\tivoli\lcf\dat\1\startlcf.exe
Start the LCFD.EXE program from the command line using options to identify the correct gateway (Tivoli Management Gateway). For example, some companies have one gateway that the whole company logs into. Others have many different choices. The Tivoli Administrator will provide this information.
Start the Tivoli Management Agent: C:\Tivoli\lcf\bin\os2-ix86\mrt\lcfd.exe with the following options:
Note: | Options are case-sensitive |
Option | Function |
---|---|
-C working directory | (Uppercase C) This causes the TMA to change the working directory to working directory when starting. The value should always be C:\Tivoli\lcf\dat\1 |
If the TMA is started without the -g option the endpoint will immediately broadcast a message in search of a Tivoli Management Gateway on its subnet. This is not recommended for most customers. Therefore, please use the following options to specify a Tivoli Management Gateway. | |
-g gateway+port | Contacts the specified Tivoli Management Gateway for initial login. gateway_address is the hostname or IP address of the Tivoli Management Gateway that the endpoint will log into. port is the listening port of the gateway. |
-p port | Contacts the gateway on the specified port. port is the listening port of the gateway. |
-P port | (Uppercase P) Specifies a local port for use by the TMA. port is the listening port of the TMA. |
To view a Usage statement and see all of the options that can be used in starting the endpoint, run C:\Tivoli\lcf\bin\os2-ix86\mrt\lcfd.exe -s -D?
This computer has the Tivoli Management Agent installed in an inactive state.
If you want this computer to become part of your Tivoli Enterprise, you will need to activate or wake up the agent. The Tivoli Enterprise includes a computer with a gateway where this TMA will log in. As user or system administrator, you can ensure that the TMA is activated correctly and joins the Tivoli Enterprise by following the instructions in this section. This process only needs to be performed once. After this activation, the TMA is running on the computer and is configured to start and log in to the TMR every time the computer starts.
Note: | Even though the steps in this section are in a certain order, they can be performed in any order. The first step is not necessary to start the TMA but is necessary for running of Tivoli methods once the endpoint joins the TMR. |
Add an entry to the run= entry in the WIN.INI file: run=c:\tivoli\lcf\dat\1\startlcf.exe
Start LCFD.EXE from the command line using options to identify the correct gateway (Tivoli Management Gateway). For example, some companies have one gateway that the whole company logs into, others have many different choices. The Tivoli Administrator will provide this information.
Start the Tivoli Management Agent:
C:\Tivoli\lcf\bin\win3x\mrt\lcfd.exe with the following options:
Note: | Options are case-sensitive. |
Option | Function |
---|---|
-C working directory | (Uppercase C) This causes the TMA to change the working directory to working directory when starting. The value should always be C:\Tivoli\lcf\dat\1 |
If the TMA is started without the -g option the endpoint will immediately broadcast a message in search of a Tivoli Management Gateway on its subnet. This is not recommended for most customers. Therefore, please use the following options to specify a Tivoli Management Gateway. | |
-g gateway+port | Contacts the specified Tivoli Management Gateway for initial login. gateway_address is the hostname or IP address of the Tivoli Management Gateway that the endpoint will log into. port is the listening port of the gateway. |
-p port | Contacts the gateway on the specified port. port is the listening port of the gateway. |
-P port | (Uppercase P) Specifies a local port for use by the TMA. port is the listening port of the TMA. |
To view a Usage statement and see all of the options that can be used in starting the endpoint, run C:\Tivoli\lcf\bin\win3x\mrt\lcfd.exe -s -D?
Obtaining the very best performance from a network adapter is not always a simple task. IBM adapters and their device drivers undergo extensive performance analysis in order to derive the best default configuration for the majority of possible configurations in which they are going to be placed. However, each environment introduces specific characteristics that affect the ability of the adapters and device driver to achieve the highest performance. IBM adapters and their device drivers are engineered to allow the user a great amount of flexibility to tune the performance in their specific environment. This includes not only many performance-based configuration parameters but also enhanced functions whose sole purpose is to achieve the highest performance possible, such as Route Switching and Class of Service for IP.
Tuning network adapters for the very highest performance is such a large topic that it is best addressed in a separate document. The following URL will take you to an IBM white paper explaining steps to achieve the best performance from your IBM adapters for your specific networking environment:
http://www.ibm.com/networking/per/per10.html
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering the subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:
IBM Director of LicensingFor license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to:
IBM World Trade Asia CorporationThe following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or program(s) described in this publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information is for planning purposes only. The information herein is subject to change before the products described become available.
The following terms are trademarks of International Business Machines
Corporation in the United States, other countries, or both:
IBM |
AIX |
AS/400 |
CallPath |
CICS |
LANDP |
LANStreamer |
Micro Channel |
Nways |
Operating System/2 |
OS/2 |
RS/6000 |
SystemView |
System/370 |
VTAM |
Wake on LAN |
Tivoli, NetView, and Tivoli Ready are trademarks of Tivoli Systems Inc. in the United States, other countries, or both.
Intel is a trademark of Intel Corporation in the United States, other countries, or both.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Microsoft, Windows, and Windows NT are trademarks of Microsoft Corporation in the United States, other countries, or both.
UNIX is a registered trademark in the United States, other countries, or both and is licensed exclusively through X/Open Company Limited.
Other company, product, and service names may be trademarks or service marks of others.
The following additional license terms apply to the Novell IntranetWare Client for DOS and Windows 3.1 code, included with IBM's LAN Client program. In the event of any inconsistency between the following terms and the terms of the IBM License Agreement for Productivity Aids, the following terms shall prevail.
IF YOU DOWNLOAD OR USE THIS PROGRAM YOU AGREE TO THESE TERMS.
The IBM program you have licensed may be designed to run in a single computer system only, or it may contain modules designed to run in multiple computer system environments. The type of environment that applies is limited by the definitions that follow:
SINGLE USER PROGRAM means a program which operates on an intelligent single-user device by which the device acts as a standalone system or a peer system on a Communications Network
COMMUNICATIONS NETWORK means a computer system which allows a number of independent computing devices to communicate with each other
NETWORK HOST OR NETWORK SERVER means a single machine on which a Host program or NLM or VAP operates to provide the host or server resources to the other machines in a network
HOST PROGRAM means that portion of the NetWare network operating system that executes on the Network Host or Network Server
CLIENT PROGRAM means that portion of the NetWare network operating system that executes on the personal workstation
NLM PROGRAM OR VAP PROGRAM means an application program that executes under control of the NetWare network operating system on the Network Host or Network Server
DOCUMENTATION means the manual(s) and other printed material packaged by IBM with the Program
If you have licensed a Host Program, an NLM Program or a VAP Program, and/or Client Program, you are authorized to 1) use one copy of the Host Program on a single Network Host or Network Server; 2) use a single copy of an NLM Program or a VAP Program on a single Network Host or Network Server; and 3) use the Client Program, and to, without additional charge, reproduce and use copies, subject to the limitation identified in the Program Documentation, of the Client Program, in support of the Host Program.
The following symbols are used in this glossary:
The following cross-references are used in this glossary:
Note: |
---|
Do not use the term application in place of application program. |
Note: |
---|
Not to be confused with connect, which implies physically connecting a device to a network. |
Note: | A bridge connects networks or systems of the same or similar architectures, whereas a gateway connects networks or systems of different architectures. |
Notes:
Note: | The DLC layer is usually independent of the physical transport mechanism and ensures the integrity of data that reach the higher layers. |
Note: | The term hard disk is also used loosely in the industry for boards and cartridges containing microchips or bubble memory that simulate the operations of a hard disk drive. |
Note: | The phrase input/output may be used in place of input/output data, input/output signals, and input/output process when such a usage is clear in context. |
Note: | The operating principles of a network include those of services, functions, and protocols. |
Note: | The AIX operating system is IBM's implementation of the UNIX operating system. |